Parallels Desktop 5.0 for Mac Run all the applications you need without switching between Windows and Mac OS X! Better integration of Mac and Windows. Supports Windows 7 Aero, with graphics peformance up to 7 times greater than before. Supports Apple trackpad gestures, new Crystal mode, speech recognition, good notebook battery life, and more.

---

Windows 2000 Server and Macintosh

Known Bugs and Cross-platform Issues

Win NT SFM problem in Win 2000 domain model. Microsoft KnowledgeBase article Q225152 reports of a problem with Windows NT Services for Macintosh running in a Windows 2000 domain. In this case, Services for Macintosh doesn't start, but yields one of three error messages. Microsoft has a "hotfix" for the problem, but you must contact Microsoft Product Support Services to get the fix. (This requires a paid tech support telephone call.)

Windows 2000 Server SFM bug with user profile

March 1, 2000 -- An InfoWorld bug report about Services for Macintosh in Windows 2000 Server, Advanced Server, and Datacenter Server. The bug gives you an error message when you have a user profile on a Macintosh volume. InfoWorld says a fix will be included in the first services pack for Windows 2000. You can also get a fix from Microsoft. (Thanks to Jeff Lucia for the tip.)

For additional reports and observations, see reader reports below.

A Look at Benefits for Mac Users

Introduction

This report is looks at Microsoft's Windows 2000 Server and its support of Macintosh clients. The server versions of Windows 2000 (formerly know as Windows NT 5) come with an enhanced version of Services for Macintosh, which is the subject of most of this preview report. Windows 2000 Server adds significant new features to Services for Macintosh not found in Windows NT Server 4.0.

Windows 2000 first shipped on February 17, 2000.

File Services for Macintosh

One of the more significant enhancements to Services for Macintosh in Windows 2000 is support for the Apple File Protocol (AFP) over TCP/IP, which is now functioning. (AppleTalk is still supported as well.) The main benefit that TCP/IP has over AppleTalk is data transfer speed. TCP/IP is a streaming protocol, while AppleTalk has not. However, Microsoft claims it has been able to create additional performance improvements to TCP/IP file sharing beyond what the protocol alone would net. At this point, file sharing over AppleTalk runs at about the same speed in Windows 2000 as it does in Windows NT 4.0.

TCP/IP support is built into a new user authentication module (UAM), which is optional, as it is with Windows NT 4.0. (Mac users can also use Apple's encrypted UAM to logon to Windows 2000 Server.) If both AppleTalk and TCP/IP are available, the new Microsoft UAM will choose automatically TCP/IP. The user can select AppleTalk, if available, with the option key.

The Microsoft UAM supports longer passwords than the Apple UAM--up to 14 characters rather than 8.

Windows 2000 Services for Macintosh requires that Macs run at least AppleShare Client 3.8, which shipped with Mac OS 8.5. AFP over TCP/IP began in AppleShare client 3.7, but Apple didn't supply a UAM API until version 3.8. Microsoft also warns that a bug in AppleShare Client 3.7.x can cause problems with the old MS UAM when attempting to connect to a Windows 2000 Server -- the AppleShare client prevents a TCP/IP connection, and doesn't list an error message.

Additionally,Windows 2000 Services for Macintosh now correctly reports volume sizes and remaining space on volumes greater than 4 GB in size. (Windows NT does not.) However, a new problem is that it reports incorrect sizes of files.

NTFS Benefits

Like NT 4.0, Windows 2000 Services for Macintosh requires NTFS volumes. However, NTFS in Windows 2000 has several new features, and Services for Macintosh can take advantage of all of them. One feature is system filters. For example, you can install a file system filter that can encrypt and decrypt data as it is written to and read from your hard drive. Other new NTFS features useful to SFM are disk quotas and remote storage.

With the new NTFS of Windows 2000, security for Services for Macintosh is the same as for PC users. In Windows NT 4.0, security for Mac and PC users is separate, even when they share the same data. NetWare has had this feature for some time. (Thanks to Fergus Hammond of Adobe for the info about security.)

Remote Access

Macintosh client will be able to dial into Windows 2000 Server using the Remote Access control panel of Mac OS 8.5 and later and the older Apple Remote Access product. Windows 2000 supports the Apple's own AppleTalk Remote Access Protocol (ARAP), as well as the AppleTalk Control Protocol (ATCP), which enables AppleTalk over a PPP connection.

Since UAMs are used for server authentication, Windows 2000 Services for Macintosh supports remote logon to a server using either Apple's native user authentication module (UAM), or the Microsoft-supplied UAM on the Mac client.

Virtual Private Networks

Virtual Private Networks encrypt information and encapsulating network traffic over a TCP/IP link, such as the Internet. Windows 2000 uses the IP Security protocol (IPSEC) for in for encrypting IP traffic. Windows NT 4 uses Microsoft's Point-to-Point Tunneling Protocol (PPTP) for dynamically assigning IP addressing. Mac clients can use Efficient Systems' TunnelBuilder in order to implement PPTP and the MS-CHAP authentication on the Mac client.

Windows 2000 will add a second tunneling protocol for Virtual Private Networks, the Layer 2 Tunneling Protocol (L2TP), an IETF draft specification. Windows 2000 supports using L2TP to tunnel AppleTalk (as well as IPX ) over a VPN. Network TeleSystems TunnelBuilder 5.0 (to be released in February), will support L2TP on Mac clients. L2TP has some advantages over PPTP, in that it is easier to get encrypted VPN sessions through firewalls. L2TP uses UDP Port 1701, which most Firewalls allow to pass more readily than PPTP's GRE port 47.

Another useful new capability enables Mac users to gain access to both the AppleTalk and IP networks simultaneously when they're tunneled into Windows 2000 Server running AppleTalk. The AppleTalk access is available over PPTP/L2TP because of Windows 2000's support of the ATCP protocol. Again, the Mac will require a third-party PPTP/L2TP client for Mac such as TunnelBuilder 5.0.

There are some additional VPN solutions listed on the MacWindows Network Solutions page. We also have a VNP Special Report page.

We also have some reader suggestions for VPN connections below, as well as on our Cross-platform Airport special report.

Printing

At this point, Microsoft is not planning to upgrade the Postscript interpreter that enables Macintosh clients to print to non-Postscript printers. The interpreter emulates an old LaserWriter Plus V.38. This interpreter prints at a maximum resolution of 300 dpi and in black and white only, regardless of the capabilities of the printer.

Windows 2000 Server Management

Administration in Windows 2000 is significantly simplified. Administration for Services for Macintosh is combined with services for just about everything else in a new window called the Microsoft Management Console (see figure below). The Console combines the administration of users, services, resources, domains, shares, and other topics. You select the area of you need to manage on the left, and the appropriate related information is displayed on the right.

You'll also be rebooting the server less frequently than in Windows NT Server. You no longer need to reboot the server after changing most settings. This includes turning AppleTalk on or off, adding Services for Macintosh, and binding a protocol to a service or network adapter.

A Closer Look

Win 2000 File Service for Mac doesn't support SLP, MCS

Windows 2000 File Service for Macintosh (FSM) does not support Open Door's Service Location Protocol (SLP) version 2, which is used in the Mac OS Network Browser to see AppleShare-over-IP servers by name. This means to log on, you either type in the IP address of the Windows 2000 server. You can use the Chooser, which requires that AppleTalk also be running.

Reader test data: faster than NT SFM, slightly slower than MacServerIP

March 2, 2000 -- Marko Rakar did some tests with Windows 2000 File Services for Macintosh and found file transfers to be more than 5 times faster than NT Services for Macintosh. However, he also found slightly slower than MacServerIP on Windows NT. Rakar also had some other observations in his report:

I have tried to compile simple data regarding my server performance after Windows 2000 upgrade. My file server has 256 MB RAM, ultraEIDE33 hard disks from Maxtor and AMD/450 MHZ K6II processor.

My conclusions are following:

Although working at the server console seems slower then on NT4, the system overall performance of Windows 2000 is teh same or slightly higher than that of Windows NT 4 SP6a. Windows 2000 is also much more stable and includes many more features over NT4 which are worth upgrading, especially if you have PCs in your network. Plenty of networking facilities are improved and system install and maintenance is much simpler (plenty of useful wizards and step by step guides, help files are also extensive). One of the biggest features is Internet integration. This means that it is possible to fully control printer spools with your local copy of Internet Explorer, and that FTP to and from server can be used instead of native Apple file share protocol.

While testing transfer speeds, I have found that transfer to the server is usually faster than file transfer from the server, but this can be easily explained by limitations of Macintosh equipment used in the test. For example, average read from server to Power Computing clone Mac machine was 596 kb/sec with SFM, 3.386 kb/sec using NT4 and MacServerIP and 3367 kb/sec using Windows 2000 AFP support. All tests are repeated 30 times, and this is average data. Similar results were noticed on other Mac computers as well (on both 100 Mbit network and 10 Mbit switched network).

Problems with installation, performance not impressive

March 16, 2000
Marcus Reese

I've upgraded a twin Pentium Pro 200 HP Netserver with 392 MB of memory to Windows 2000 Server. It took about a week to install. I had to replace some of the NICs with newer ones-- the old ones weren't seen by Windows 2000. This would only work with Windows NT installed first: a new install would not work. Windows 2000 also didn't like the RAID controller card (which is approved by Microsoft). It would install on a single drive but not on my 6-drive RAID.

The overall system speed is slower than NT 4.0. File sharing seems to be as fast as my AppleShare IP 6.3 servers. Still can't print to HP LaserJet 5Si printers without getting random print errors. AppleShare limit of 4 GB in client windows is gone, now show correct size of available space on mounted volumes.

Mac users can't change W2K domain passwords

Note: there is now a Microsoft hotfix (see KnowledgeBase article Q328417) available for this problem. (An older Knowledgebase article Q306485 on this topic was removed.) Additionally, as of March 2003, Microsoft is saying that using the Microsoft UAM on the Macintosh client will prevent the problem.

March 22, 2000
Charlayne Beavers reports of logon problem for Mac users on a Windows 2000 domain:

We are running two Windows 2000 Servers. One is the Domain Controller, the other is a member server for file sharing. We have File Services for Mac running on the file server and have placed accounts on in the Active Directory. We have password set up so the first time the user login they are prompted to change their passwords. If a NT 4.0 workstations, Windows 2000 Pro workstation, Win95 or 98 workstations logon all proceeds fine and the password changes not matter what platform the user log ins.

If the the user logins the first time with a Macintosh the password is changed and it is fine on all platforms except for the Windows 2000 Pro and Server platforms. These platforms continue to think the initial password is still viable and that it is not expired. If you go back to Mac or any other windows client they require the new password not the expired one.

I checked the knowledge base at Microsoft and there does not appear to be any mention of this so I thought I would check here.

I am using the Microsoft UAM installer which comes on the Windows 2000 server and I am running Mac OS 8.1 but have upgraded my AppleShare Client to 3.8.3.

August 18, 2000 --
Urban Wallin reports

We have a little NT4 domain that contains about 80 servers. After a little complaining we managed to get approval to install a Windows 2000 server (as a member server) so I can get the speed for my Mac users.

We discovered a strange problem; the users can´t change their passwords (domain level) thru the Windows 2000 Server.

August 21, 2000 --
Seth Bokelman

I've had the same problem here, and it gets even weirder than that. If I create a new user, and check the "User must change password at next login" box, and the user then logs in with a Mac, they are prompted to change their password. If they then go to a PC, their new password does not work, but their old one will! However, from a Mac, the new password works, so in effect, the user has two passwords for the same account. Changing their password again from a PC seems to clear up the problem.

October 3, 2000 --
Mike Maday

We experienced all the same issues with a user resetting their password from a Mac workstation, only to have it seemingly not be recognized by the domain controller(s) when that same user logged on to a PC. We found a solution! ExtremeZ-IP. It didn't have the lost-Mac-password issue and supports Apple-encrypted passwords, rather than the insecure clear text type, for authentication. This means we don't have to touch any Mac clients to install any MS UAMs!

Aliases to Windows 2000 Server

March 22, 2000 -- Tim Fisher suspects that aliases to Windows 2000 Server only work when all the Macs on the network are using the same UAM:

From what I can tell, if you enable support for more than one UAM on the server, then two bad things happen: From the Chooser users will get an additional prompt asking them to select a UAM before logging on. From an alias, instead of the "choose a UAM" box, they get an error message.

I suspect what makes aliases fail is when the server supports more than one UAM. My aliases work now because I set my server to allow Microsoft authentication only. If you set your server to Microsoft authentication only, you get all the benefits: all the aliases work, you get secure encrypted authentications, you don't have to allow reversible-encryption passwords in the Active Directory, all the users & passwords are integrated with Windows 2000 with NO extra typing or work, and your users don't get the confusing "select a UAM" box. The only downside is that you MUST install the Microsoft UAM on all the Macs that want access.

Windows 2000 SFM getting time stamps wrong

Since this has turned out to be a problem that occurs with Windows NT as well as Windows 2000, we've moved this discussion to it's own page.

Problems with Index file, MS UAM, and comment on performance

July 19, 2000
Rui Martins

Two Problems with Windows 2000 Server SFM:

Here, at Yellow Pages (Portugal) we had recently installed a W2K Server with SFM. We were forced to do it because of the known limitation of 4 Gb for accurate size measure in Windows NT 4 (all Service Pack), a silly limitation that was finally solved by Redmond in W2K. But we had found two problems:

a) The very old problem (as old as Win NT SFM, in fact) of the AFP_Index files in VM not being updated is still present in W2K. Fortunately, the old solution of creating an temporary folder, deleting the Mac Share, moving all files to the temp folder and creating-renaming the folder still works. The main difference is that now we can see some errors in EventViewer:

Event ID: 12004 -- Unable to write internal server information to file "\dgslb07$:AFP_IdIndex".

*** And that´s really the MacVolume that has files disappearing from the Mac clients, but still visible in the Wintel shares.

Event ID: 12051 -- Unable to update the index database for the Macintosh-Accessible volume "dgslb07$1". There may not be enough disk space."

*** That´s not true. I still have 1.7 Gb free on that disk...

b) The new Microsoft Authentication V5.0 (for AppleShare 3.8) seems to have some problems... I´m still not sure, but it seems that´s with it is simply not possible to mark the option to automatically mount the volumes in the next Mac boot. Using the standard Apple UAM the option is available. The message is: "Startup mounting is currently not supported for this log on method". I supposed that´s "by design"...

A final remark:

Although MS claimed a "performance boost" with W2K, our performance tests, in the "real world" show little or none improvement in that area, comparing two servers, same hardware (exactly), but Win NT SP6a and Windows 2000 Server (and both Member Servers).

MS UAM 5.0.9 is still incompatible with Multiple Users

November 30, 2000
Joerg Erdei also reports having a problem with the Microsoft Authentication v5.0 reported above ( "The new Microsoft Authentication V5.0 (for AppleShare 3.8) seems to have some problems..."). He also offers some other comments about the MS UAM.

If I understand Rui Martins correctly, he only gets the "Startup mounting is currently not supported for this logon method" with the Microsoft UAM, not the Apple one. I also have this problem, independent from Mac OS (8.1-9.0.4), AppleShare version, UAM version (v5.0.4, v5.0.5), Server version (NT 4, Win 2000, Win 2000+SP1) and protocol (TCP/IP, AppleTalk).

Another big problem is: Microsoft UAM is not multiuser compatible. Only the Mac's administrator can use it. All other users are put back into Chooser and will never see the user/password dialog. (Tested with Microsoft UAM v5.0.4 and 5.0.5).

Not only the Microsoft UAM will automatically choose TCP/IP where available, the Apple UAM does it the same way, and also offers the option key trick to connect via AppleTalk instead of TCP/IP. To be more accurate: this seems to be UAM independent, for the option key must be held when you select the server, before you even get the choice between the available UAMs. The key advantage of the Microsoft UAM is: longer passwords (up to 14 characters instead of 8)

April 24, 2001
Joerg Erdei

A little update to Multiple Users incompatibility of MS UAM:

* In addition to the Admin, 'Normal' users can use the MS UAM too. [

* Using the Chooser, 'Limited' and 'Panels' are simply put back into the Chooser server selection window and will never see the user/password dialog. Using Network Browser a error message pops up:

The server "yourserver" cannot be found.

* Tested with: Microsoft UAM 5.0.4, 5.0.5, 5.0.7; Multiple Users (=Macintosh Manager Client) 1.1, 1.2.4, 1.3, 1.4, 1.4.1

SFM Server disappears from Chooser: mostly with Service Pack 1

Some people also see this problem without SP1, though less frequently. Microsoft offerred some suggestions, below, which some readers reported didn't work. However, serveral readers report fixes that work for them.

This problem sounds similar to a know issue with AppleTalk printers and other devices disappear from Chooser, caused by use of the Spanning Tree Protocol on switches.

This report is divided into four sections:

• Initial descriptions of the problem
• Suggestions from Microsoft
• Suggestions and fixes from readers
• Problem with multiprocessor servers -- known bug, hot fix now available.

Initial descriptions of the problem:

August 4, 2000 -- Dan Tesch reports a problem that Service Pack 1 appears to cause with Services for Macintosh:

I installed SP1 yesterday and my server does not broadcast its name in the Chooser for the Macs anymore. It definitely did prior to the update. I can still connect by typing in the IP address.

I de-installed SP1 and the server reappeared in the Chooser, reinstalled the SP and it disappeared again.

August 7, 2000 -- Roland E. Miller, III reported the same problem with Windows 2000 Service Pack 1 that we reported last Friday:

I can confirm that when I installed SP1 on Windows 2000 Server, the server failed to show up on the AppleTalk network. I can also confirm that connecting via the IP address works.

I have removed SP1 and the server shows up again in the Chooser on our Macs.

August 8, 2000 -- Paul Tornaquindici says that File Services for Macintosh was turned off by the Service Pack 1 installation

I too had the same issue. I looked at the services menu and the Mac Services (Mac AppleShare File server) was NOT STARTED after the update. Simply start the service and make sure automatic is selected and all is well.

However, other readers have reported being able to log in to the server by typing the server's IP address in the Chooser, which indicates that File Services is turned on in their cases.

Suggestions from Microsoft

August 8, 2000 -- Microsoft told MacWindows that they are looking into our reader reports of problems with Services for Macintosh when Service Pack 1 is installed on Windows 2000 Servers. (The server no longer shows up in the Chooser.) At this point, Microsoft is still looking into the issue.

In the meantime, Ethan C. Allen of the Microsoft NT SFM Lab offered a couple of suggestions to try:

1. After installing SP1, uninstall SFM and then reinstall it.
2. Switch the AppleTalk control panel connection from Ethernet to Modem/Printer or Remote only. Close the control panel, then open and switch it back to Ethernet.
3. If that doesn't work, do a reboot the Mac after installing SP1. He says "The Mac has a tendency to take a while to recognize AppleTalk networks so the IP may work but the AppleTalk might not right after SP1."

If you are seeing this problem, please let us know if these suggestions work. Also tell us what kind of PC SP1 is running on, and if your installation procedure was out of the ordinary in any way.

August 9, 2000 -- Ethan C. Allen of the Microsoft NT SFM Lab offerred further advice for problem. In order to check that SFM is installed and running after SP1 installation, he offers this advice:

Go to the "Run" item on the Start Menu and type "cmd" and then when the command window pops up, type "net start". After a SP1 install the "File Services for Macintosh" and "Print Services for Macintosh" should both show up on the list if they were installed.

More reader reports, suggested workarounds and fixes

Reader Pete Van der Goore reported that he is not seeing this problem with Macs running OS 8.x and OS 9.04.

August 10, 2000 -- Brian Kearney reports another angle:

I installed SP1, and all was well. Then today, I had to shutdown for a few hours due to a power outage. When I restarted, SFM was shown to be running, but the Macs couldn't see it in Chooser, and the service refused to shutdown. I changed it to "disabled" and rebooted. Then, I switched it to "manual" and started the service. I can see it fine now on the Macs.

Its a 600 MHz Pentium 3 clone, built by Intel. It was one of the very first PIIIs that were released, in fact, it says Pentium 2 on the CPU, but it was labeled by Intel with the code name for the P3 (which escapes me now). It was originally a developer's test machine. 384 meg of ram, no fancy hardware. Running IIS, ServU FTP, Internet Anywhere Mail Serve,and MS Fax.

August 15, 2000 --
Tim Fisher

I too have had my server name disappear from the Chooser on occasion since installing SP1 two days ago.

Restarting the MacFile service seems to have no effect when this occurs. MacFile relies on the AppleTalk protocol being installed in order to appear on AppleTalk networks. This is independent of the AFP protocol, which can of course run over TCP/IP alone, so it does not need AppleTalk to work. Therefore, if AppleTalk is unavailable for some reason when MacFile starts, then it will simply run the TCP/IP code only and ignore the AppleTalk part, leaving it uninitialized.

This procedure has worked for me at least once:

1) You may need to shut down MacFile first (I did), or you can restart it later.

2) Open "Network and Dial-up Connections" and view properties for the network interface that you want AppleTalk to run over.

3) Open the "AppleTalk Protocol" component listed in the Properties panel and make sure that the correct zone is listed there. Re-select the zone name again in the drop-down listbox, even if it is already correct.

4) Click OK, then OK again (NOT Cancel). This will reregister the AppleTalk node name for this machine on the AppleTalk zone.

5) Open the System Log in Event Viewer to make sure you see a new AppleTalk Event ID 5. It will say something like 'A name was successfully registered for this node via AppleTalk protocol on adapter "Intel 8255x-based PCI Ethernet Adapter (10/100)".' This tells you that something was wrong before, but now it has been set right. :)

6) Restart MacFile. Name will now appear in Chooser.

I am not sure if this procedure must be followed after each reboot, but it definitely works whenever the server name is not appearing in the Chooser.

This server is running on a Dell PowerEdge 2450, with RAID5, dual Pentium III processors, and 512 MB RAM. The name of the particular Ethernet adapter will probably vary in the Event Log message above.

August 18, 2000 -- Julie Smith reports not having this problem with Service Pack 1: Mac users still see the server in the Chooser after the SP1 upgrade.

September 14, 2000 --
Shawn Barnhart

I can definitely say I've experienced this and there's a bug of some kind, but what it is I don't know.

After installing SP1 and doing some other monkeying around, I noticed that my server wasn't appearing in the Chooser. I rebooted the server and it reappeared. I rebooted the server again to apply some other changes and lost it. Again. After verifying all the bits were running and rebooting again and not getting it back, I started digging around on your site as well as others wondering what was going on.

I went back to my Mac without touching the server and found that the server was appearing again. Like many others, I'm kind of lost. We've got a larger network (around 400 nodes, switched environment, over 700 nodes on other LAN & WAN segments throughout the network), maybe there's some delay in name registration or something else causing the delay.

I also wonder if SFM isn't getting started before Win2k's AppleTalk stack is ready to handle NBP requests.

Server hardware is HP Netserver LPr Dual PIII 650s, RAID-1 via HP Netraid-1si.

Turning off the spanning tree protocol

September 15, 2000
Shawn Barnhart

We use HP Procurve 2424M switches and spanning tree is disabled on them by default, and I do check to be sure when I fire a new one up...The core switches which handle server interconnects and server->LAN connects are the newer ones with current firmware and none of the upgrade notes that I've seen address this type of a problem...

The only similar problem we've encountered, which may be related, is with a select group of Digital Venturis and Celebris PCs running DEC 21x4x NICs won't get an IP address via DHCP at bootup. Running WINIPCFG.EXE out of Startup Items *will* grab an address -- its as if the machine needs an extra 20 or so seconds to get going on the network. I've run network traces at the DHCP server and the DHCP requests at initial power-on never reach the server. Strangely DHCPREQUESTs on reboots, software-initiated DHCP Releases, or standard DHCP RENEW messages are not a problem -- only very-cold-from-all-night-power-off boots were an issue.

My speculation is that Windows' network layer is getting a "link established" flag from the NIC driver but downstream switches either haven't negotiated speed or haven't updated their MAC tables to the point where the machine can actually transmit data and have the switch forward it, but because the upper software layers think there's good link there they start transmitting but it goes nowhere.

The strange thing is we've not experienced this problem with anything other than the above DEC NICs. Swapping in a 3COM or Intel NIC in those PCs made the problem go away, as did the software-only solution of retrying the DHCP lease later on.

What's this got to do with Win2K SP1 SFM? Well, perhaps its a similar problem -- NIC indicating good link to upper layers and its causing AppleTalk to not bind properly. I'm going to lock the server and the switch port at 100FDX to see if it has an impact, since both are set to auto negotiate now. That may impact this problem.

May 22, 2002
Adam Glick agrees that the spanning tree can cause this problem:

Check for spanning tree status on the network equipment (probably switched). It should be set to off.

May 24, 2002
Geoff Strickler sent in some advice about turning of the spanning tree protocol, which users have reported fixing a problem of Win 2k Servers disappearing from Chooser. Strickler says it can fix other problems as well, but isn't always possible:

In your item on items disappearing from the Chooser with Win 2k SP2 servers you mention disabling spanning tree protocol. That's a good recommendation that will eliminate many Mac and Windows networking problems, including some DHCP problems. Unfortunately, disabling STP is not an option in many larger installations because there is just too much chance of a user introducing a loop. Here are some alternatives:

Only disable STP on ports that will have or may have users directly connected to them. If the port runs to another hub or switch, you can leave STP enabled.

Some brands of switches have 'non-blocking' modes of STP startup. This allows traffic to pass on the port until STP has decided that a loop exists. Cisco calls this feature 'portfast' and you should enable this mode rather than disable STP if your switch supports such a feature.

Many switches allow you to specify the STP timeout parameters. Lowering these to 3-5 seconds rather than the 10-20 seconds they usually default to will minimize or eliminate the problem.  

Forcing the speed and/or duplex setting on the NIC in your workstations and/or on the switch ports can sometimes help as well.

More suggestions

November 20, 2000 -- Luc Teblick did some comparison testing on two Windows 2000 Servers, confirming that the problem is not limited to Service Pack 1:

Two servers, identically setup, except one an Intergraph IS90 with 2x 600 MHz, one an Intergraph ZX10 with 2 x 700 MHz. Here are our findings:

• Installing SP1 makes the problem happen more often, but we definitely have the problem also without SP1.
• The ZX10, which is faster, also has the problem appearing almost every time. The IS90 once in a few startup cycles.
• Disabling/enabling the network card, changing zones, or stopping/restarting seed routing solves the problem.
• We use in this configuration 3COM gigabit network cards. We have an identical configuration at another site, only here with INTEL gigabit cards, no 3COM. No problem there.

However, this is just the opposite of what Shawn Barnhart said about 3COM cards (message just before this one):

"The strange thing is we've not experienced this problem with anything other than the above DEC NICs. Swapping in a 3COM or Intel NIC in those PCs made the problem go away..."

December 7, 2000 -- Two readers offered solutions based on the same sentence in Luc Teblick's November 20 report above:

"Disabling/enabling the network card, changing zones, or stopping/restarting seed routing solves the problem"

Roland Miller looked at the network card, while a reader named Kelly pursued the seed router issue. Both say they have fixed the problem.

Roland Miller, updating network drivers fixes problem:

For various reasons, I had to get SP1 on that system, so I went through each of the suggestions in the archive on this subject. As a result, I believe I have some more concrete results to add to the thread (at least as it applies to my situation).

First off, File Services for Macintosh is running after SP1 install. You can connect to the server through AFP/IP. Microsoft's suggestions to solve the problem do nothing to affect it. I reinstalled SFM and AppleTalk multiple times to no avail. The problem is certainly not with the Mac clients as Microsoft suggests, so don't waste your time on the client side.

The server does not show up in the Chooser immediately following the upgrade to SP1 (or any of the latest critical updates/patches/hot fixes.) Restarting, disabling, or setting to manual the SFM services do nothing. Tim Fisher's suggested procedure did nothing for me either. In fact, on each reboot once SP1 was installed, AppleTalk says that it had successfully registered the node. This event message clearly is false.

I believe that Shawn Barnhart's commentary points to the root of the problem. When I disable and re-enable my network adapter, as suggested by Luc Teblick, the server would show up magically in the Chooser for the first time since installing SP1. I have a Gateway ALR 8200 with on-board Intel EtherExpress PRO/100+. I went through trying to turn off auto negotiate and use various settings (100 full-duplex, half-duplex, etc.) I even tried connecting to a "dumb" switch versus our Cisco Cat5000 switches to find a solution that works. Each of these scenarios produced inconsistent results.

Finally, I decided to update the drivers for the NIC. I downloaded a driver from Intel and replaced the one produced by Microsoft. After installing it and setting the settings back to default (i.e., auto negotiate to our Cisco switch) I restarted. The server came up just as it should! Right now the server has been up for some hours under typical load and everything is operating normally.

In summary, it appears that there is something weird going on with the AppleTalk stack initialization/bind phase at startup under SP1. I appear to have solved the problem by updating the driver for the NIC.

Kelly, reconfiguring seed routers fixed problem:

This sounds like a problem we had here at work - of our four AppleTalk seed routers, one became misconfigured during a clean install. Whenever this router assumed the responsibility of seed routing, servers would start dropping out of the Chooser. It would appear that when servers receive conflicting network range information, they get confused. ;-) Disabling/enabling the NIC or stopping/restarting the seed router would force another (properly configured, at least from the disappearing servers point of view) router to take over seeding zone and network range information. By changing zones on the 'confused' server, AppleTalk is requesting zone/range information from the seed router, and synching back up with the (misconfigured) seed router - also causing the problem to disappear.

September 24, 2001
Nick Collingridge also found the answer in a seed router:

In response to the item regarding Win2K servers not being visible in the Chooser, I have seen this sort of problem when there's no AppleTalk Seed Router on the network, and there's only the default zone. This can easily be remedied by using the Win2K server as an AppleTalk Seed Router. It certainly fixed some problems for me.

January 22, 2000
Daric Smith sent this basic suggestion for people not too familar with Windows 2000 SFM:

In the TCP/IP properties of the server, there is the AppleTalk protocol that must be "installed" for SFM to work. There is also a check box next to it. Checking this box enables the part of AppleTalk that gives Mac users the ability to view the server in the Chooser. If this box is unchecked, they will not see the server in the Chooser. Basically, the AppleTalk protocol must be installed, but it does not have to be active. That is hopefully a troubleshooting technique someone will find useful.

September 19, 2001
Kevin Skinner

I know I am speaking up a little late but I have the same problem on a new Win 2000 Server SP2 that we just set up. The server was not showing up in the Chooser for our Mac users but they could connect by using the IP address. It has (2) built in 10/100 NICs. Both of them had been setup and both had AppleTalk installed and checked as active. I found that the properties for AppleTalk are very slim. Just the Zone and a check box that lets that adapter accept incoming connections. I have one connection disabled (for various reasons) but the AppleTalk associated with the disabled one is the one that had incoming connections "Checked". As soon as I checked it on the other Windows informed me that I can only have incoming connections on one NIC so the other one is now unchecked for me. Now the users can see the server in the Chooser and all is well.

May 28, 2003
Emmanuel Etiévent verified the above solution.

For me too, I had to set "Accept connections on that adapter" in the AppleTalk properties to make appear the server in the [OS 9] Chooser (access from "Network and remote-access"). It works even if the zone dialog box was blank. We have Windows 2000 SP2.

May 22, 2002
Jim Van Veghel told us about a solution for a similar problem printers:

This sounds like a problem I had with printers. They would sometimes appear in the Chooser, then disappear, then reappear. The solution was making sure everyone's AppleTalk control panel had unique network and node values. There were overlapping net/node values and if both people had the Chooser open, only one could see the devices.

Another fix: use uniprocessor PC setting instead of multiprocessors--a known bug.

Microsoft now has a hot fix for the problem on Multiprocessor systems as described in the September 26, 2002 report below.

May 30, 2002
Bill Grabowski

In setting up servers for the Minneapolis Star Tribune, I have run across this problem. I'm using Compaq DL380's with Dual 1 GHz processors. If I go into Device Manager, Computer and change from 'ACPI Multiprocessor PC' to 'ACPI Uniprocessor PC' and reboot, the problem disappears. It seems to be related to the Dual-CPU HAL. I have a case open with Microsoft.

June 5, 2002
Johan De Deyne

I would like to confirm the solution presented by Bill Grabowski, I am currently installing a Compaq ML350 G2 and I have tried all the suggestions given before, none did the trick except for the ACPI Uniprocessor Device Driver.

Microsoft action comming.

July 19, 2002
Bill Grabowski

The Problem: Multiprocessor systems running Win2K with SFM will not show up in Chooser after a reboot.

In May, I submitted a workaround to MacWindows.com (switch from multi-processor to uni-processor in Device Manager), which works every time; unfortunately, it also takes you down to a single CPU. I've been working with Microsoft since then, and now have a better understanding of the problem. Certain NICs, with certain chipsets, fail repeatedly; while others never fail. I have just installed 3COM NICs (Model 3C905CX) into my dual-CPU Compaq DL380s, and have not had the problem since. (*Not all 3COM NICs work - the Model 3C996 Gigabit card fails).

I now have a case open with Compaq. Below is an explanation from a Microsoft engineer of the problem:

...we've identified that the problem occurs because the AppleTalk Multicast Address is not properly registered to the adapter. The Registration of the Multicast Address occurs at a Hardware level from the Driver to the card.

This was confirmed with your system, as well as multiple systems here running with Intel Network Adapters, or adapters running with an Intel Chipset on multiprocessor systems. To be as specific as I can, the NDIS Layer of the protocol stack exposes a Hook for Drivers so when AppleTalk, or any protocol attempts to register a Multicast address to the physical Adapter, it sends the request to the Driver for the specified Network Adapter, and the Driver is responsible for making the registration successfully. In all cases of our testing here, 3COM, AMD, Linksys and DEC Network Adapters receive, process and return a successful response to the request.

This was confirmed via the Application written (MCENUM.EXE), as well as by the Mac's ability to view the server. With a Compaq Network Adapter running with the the Intel 82559 Chipset, an Intel PCI 10/100, and an Intel PCI 100 S-Management Adapter, these requests made to the Driver were returned successfully, yet were not registered with the Physical Adapter.

This was confirmed with multiple Network Adapter Drivers (Microsoft, Compaq, Intel).

September 26, 2002
Bill Grabowski reports that Microsoft has a hot fix for the problem. Grabowski sent us a long report from Microsoft that describes the problem. He also told us that he as tried the Microsoft hot fix and confirms that it fixes the problem:

The Problem: Multiprocessor systems running Win2K with SFM will not show up in Chooser after a reboot. In July, I wrote the description of this problem and said I had a case open with Compaq. After further testing, the case was closed with Compaq and reopened with Microsoft. They resolved the problem and have a Hot Fix for it. Below is the description of the problem and the fix:

ISSUE

A Multi-Processor Windows 2000 Server running File Service for Macintosh will fail to register the AppleTalk Multicast Address appropriately on an inconsistent manner. The multicast registration failure is seen by the Macintosh clients who can no longer view the Server in the Chooser under it's expected Zone. The 2000 server will display that it is still in the correct zone, via the Network Connections. The problem is only seen on systems with the following configurations:

1. Network Adapters with the Intel 8255x-based chipset.

2. Symptoms only exist on MultiProcessor Computer Systems

CAUSE

Based on a live Kernel mode debug of a System experiencing the problem, it was initially determined that the Operating System makes a request to Register the Multicast Address to the Network adapter via the Adapters Kernel mode Driver. The Driver returns back that the registration is successful, yet, once complete, enumeration of the Multicast entries being listened to by the adapter shows that it has not registered the AppleTalk Multicast address. Via discussions with intel Development, and being provided with a debug level Driver from Intel, it was determined that there is a possible secondary cause.

Symptoms are sporadic, in that, sometimes the Multicast Registration is successful, other times it is not. As investigation has continued, it has been identified that we send 2 simultaneous requests to Set the Multicast list. One to update the list, removing any possible old Multicast entries that are no longer used, and one that is meant to fill the list with the updated information.

On Multiprocessor systems with Intel Network Adapters, the request containing the list that we want to remove, sometimes comes AFTER the list we want added to the adapter.

The reason this may be seen only with Intel based Adapters appears to be due to the timing in how the Intel Driver responds to the requests.

PLAN OF ACTION

A bug has been filed with Microsoft Development on this with the detailed information.

RECOMMENDATIONS

To work around the issue by switching to another non-Intel based Network Adapter.

A couple weeks after this description, the Final Packaged and Supported Hotfix was given to me by Microsoft. It replaces one file: SFMATALK.SYS. It is in production and is working fine here at the Minneapolis Star Tribune with the Intel based NICs that used to fail.

The Microsoft Knowledge Base number for this issue will be Q327360 after it is edited and placed on their website.

An update on the hot fix

December 31, 2002
Tim Friez

We had the same problem as noted in the article. We took a shot and contacted Microsoft with the Microsoft Knowledge Base number Q327360 that was supplied on your web site. With no hassle they gave us a link to there FTP site with the hot fix to run on our server. They said it was still in testing so we had to use it at our own risk. After almost two month of running with the patch we have had no problems since.

Win 2k reports incorrect file sizes

Many readers have reported this problem. Below their reports is an explanation for the problem. On April 10, 2001 Microsoft created a hotfix (not included in Service Pack 2), described in Knowledge Base article Q277862:

Services For Macintosh on Windows 2000-based servers do not properly respond to file-size queries from Macintosh clients.

As with most Windows server hotfixes, you need to call Microsoft support to obtain the update--it is not posted at the Microsoft web site.

September 14, 2000 -- Dave Harty reports that Windows 2000 Server is reporting incorrect file sizes to Macs:

We have a brand new Dell server running Windows 2000 with SFM (no service packs). We use this machine to hold all of our Creative files. It was brought to my attention that all of our Quark files now have a file size of 5.1MB. If you do a Get Info on the file it will give you the correct size however. I haven't found any mention of this on the MS site, Quark or your forums. It affects OS 8.5.1 and up as far as I can tell. Windows machines will report the correct file size.

September 15, 2000
Jeff Churchwell

Our company has noticed the identical problem to the one reported by Dave Harty. Win2000 reports file sizes of 5.2 Mb on a variety of file types, including Photoshop and Illustrator files. We are running Win2000, no service pack.

September 22, 2000
David Dutt describes

Our users have been noticing incorrect file sizes also. If we Get Info on the files, it shows the proper size in parenthesis. We see the same thing as Dave Harty and Jeff Churchwell. Most files under 5MB appear as 5.2 MB. Other sized files show sizes closer to their actually size. For example, we have some 10 MB files that show up as 13 MB.

October 16, 2000 --
Seth Anderson

We are running a newly formatted Win2K server with SP1 and File Service for Mac, but no Apple Talk. Many of our image files are showing up with incorrect file sizes, either in the folder view or when I get info on the file from a MAC OS 9.0.4 client. Files as small as 60 k are showing up as 4.7 MB. I have seen that other people are having the same problem. PC's of course see the files correctly.

Win2k file size problem NOT linked to directory location

October 20, 2000 -- We've had numerous reports that the problem of Windows 2000 Server reporting incorrect file sizes to Mac clients is NOT related what directory the shared Mac volume is located in. (We had speculated that a root-level Mac volume might cause the problem.)

Also, a few interesting clues:

• Two readers that when Mac OS X Beta logs onto the server, the file sizes are correctly displayed. This tends to point to something on the Mac OS 9 or ealier. (Thanks, Jeff Churchwell, and Tony Gentile)
• Get Info: Bryce Steiner points out that the Finder's Get Info boxes for the files do report the correct file sizes. He added "The smallest my Macs report are 970k, even though they aren't quite that large." (His Mac Volume is in root directory.) However, Paul Timmins reports that the Get Info reports the inflated size.

October 20, 2000 --
Scott Myers

A small SimpleText document of 8k displays 753k in each Win2k directory. Although a 14.6mb file displays as 14.6mb.

(I have created a volume share at one and two directories deep from the root directory. Each directory shows incorrect file sizes.)

October 20, 2000 --
Bryce Steiner

Steiner points out that the Finder's Get Info boxes for the files do report the correct file sizes. He added "The smallest my Macs report are 970k, even though they aren't quite that large."

October 20, 2000 --
Paul Timmins

We too have experienced the "smaller than reported" file size using Mac OS 9.0.4 viewing files on a W2K server with SP1 installed.

Most files report in at 1.1 Meg in the Finder "Get Info" window while only containing a tiny bit of information. For example, a .gif file of 8889 bytes is reported at that inflated value.

October 20, 2000 --
Tony Gentile

We're running W2K SP1 on a Compaq 1850R with a fiber channel into a Clariion FC5700 with 66 GB of storage. Our Macintosh clients are G4's running 9.04 and older 7300/180's running 8.6. The smallest file size that W2K reports is 1 MB. The Finder will report its true file size, in this case 24k.

The "Microsoft UAM Volume" that gets created when you install Services for Macintosh is a on the "C" drive and is a 4 GB share. These same files are reported as 64k in size.

October 20, 2000 --
Rob Simons

I have Win2000 with a MacShare located at c:\shares\web_sites &endash; still incorrect file sizes. Although, I do NOT have SP1 installed. I didn't think anything in SP1 addressed this issue.

October 20, 2000 --
Jeff Churchwell

I'm getting the 5.2 Mb file size reporting. I just looked at my Win2K server, and sure enough, my Mac shares are at the root level of the logical volume on which they reside (e:\macshare).

I just created a new share inside an unshared directory placed at the root level of the volume on my Win2K server, and dropped some files in it. It STILL reports 5.2Mb file sizes.

An explanation for file-size error in Windows 2000 Server

October 23, 2000 -- Rob Newberry of Group Logic, makers of ExtremeZ-IP, has sent us an explanation of why Windows 2000 Server Services for Macintosh (SFM) reports the wrong file size to Mac clients, and why NT doesn't have the problem:

Late in the development of AFP 2.2, the first version to run over TCP/IP, Apple added a special command that a client can send to a server to obtain the allocation block size on disk. This command is not documented by Apple in the AFP 2.2 documentation, but it has been discussed by Apple in a few forums. The client sends the command to the server, and the server is supposed to tell it what the block size is.

Unfortunately, the Windows 2000 AFP/TCP server does not recognize this command (I have verified this by examining the traffic with a network packet analyzer). It responds with an error, which the Mac client deals with by calculating the block size based on the same math that it used when HFS (not HFS+) was the file system. As you may recall, in the HFS days, very large hard drives had TONS of wasted space because the allocation units were so large. When Apple went to HFS+ in Mac OS 8.1, they solved this for local disks. In the next release of the OS (8.5) and with the new AppleShare client, they also solved it for remote disks (though they didn't document it very clearly). Note also that this problem is really only cosmetic -- the main problem is that the Finder displays incorrect information; the actual sizes of the files on the server's disk are not really that large.

The bottom line is that Windows 2000 simply doesn't have complete support for the AFP protocol -- specifically, it is missing this command. Our product, ExtremeZ-IP, DOES have support for this command, and works fine on Windows 2000 -- if a customer wants to resolve this issue, I of course recommend they use our solution. Otherwise, they have no choice but to wait for Microsoft to fix it -- it cannot be worked around by the customer along -- and who knows how long that will take. Updates to fix SFM-related problems have, in the past, been slow to arrive -- Microsoft has a lot of other priorities besides supporting Mac users connected to NT servers. Because ExtremeZ-IP is so much more important to us, Group Logic will always work harder to get updates into our product out the door quickly. And in this particular case, we have already solved this problem (ExtremeZ-IP has supported this AFP call since version 1.0).

As to the Mac OS X client reporting correct file sizes (reported today) -- it is _POSSIBLE that the new Finder in Mac OS X no longer displays allocation sizes, but instead displays the "logical" size of the file only. I have not looked at this particular issue with the Mac OS X client yet to verify the report, primarily because I knew ExtremeZ-IP already did the right thing. I have been looking at some other new functionality that Mac OS X clients will enjoy, and we hope to have a major announcement about that after ExtremeZ-IP 2.0 ships.

Windows NT

This command was introduced in AFP 2.2. Windows NT 4 only supports 2.1 (which is the primary reason it doesn't support TCP/IP connections, only AppleTalk). It's also the reason NT 4 can't tell you that a drive is bigger than 4 GB (also introduced in AFP 2.2, but well documented and supported by Windows 2000).

I don't exactly know why NT 4 doesn't exhibit this behavior, but it probably has to do with the way the Mac does the calculation. When the client doesn't support the special AFP command to get the block size, then it estimates the block size by dividing the volume size by some number (I do not know what that number is exactly). In Windows 2000, the volume size MAY be very big. But under Windows NT 4, the volume size could never be bigger than 4 GB. When it divides 4 GB by the this number, the calculated allocation size is much smaller. So the problem doesn't APPEAR to happen, although it may still be there.

Further explanation of the problem

November 30, 2000 -- Joerg Erdei offers further explanation the Windows 2000 file size reporting error. He also argues that the problem is not merely cosmetic.

When I first recognized that problem I did the math: partition size/65536 equals exactly the minimum file size the Mac reports on Win 2000 server volumes, so Rob Newberry is right stating that the server volume is treated as a simple HFS volume with its maximum 65536 allocation blocks. Windows NT servers only report up to 2 (or 4) GB disk size to Mac, the same math gives 32 K (or 64 K) minimum file size, and again that is exactly what the Mac shows. Remember that this minimum size is per fork, so on a 100 GB volume a file of a few bytes containing both data and resource fork will be reported as being 3.1 MB (3200 K) if located on a Windows 2000 server and as 64 K (or 128 K) on a Windows NT server.

Other then Rob I don't think of the problem to be cosmetic: when copying many small files to the server the Mac may tell you there is not enough space to do it, although the files would occupy only a small fraction of the available server disk space. Copying the files in smaller groups works. This is really inconvenient if you just wanted to quickly copy one folder, but now have to create a folder on the server and copy the files in small chunks just because the Mac thinks the server is HFS. This happened to me several times. Imagine doing a quick backup copy of a OS 9 System folder (in my case 375 MB), you cannot do this in one step if do not have at least 10 GB free on a 100 GB disk array.

December 27, 2001 -- Joerg Erdei adds

Regarding Knowledge Base article Q277862 you should point out that the hot fix is not included with SP2; I asked Microsoft to update this article to include Windows 2000 Server SP2 in the 'applies to' list without avail a long time ago.

AppleShare Prep file corruption and Win2k Server

September 15, 2000
Jeff Churchwell notes a problem with corrupted AppleShare prep files in Mac clients:

We have rebooted the Win2000 server a number of times in the last two weeks, and have noticed that Mac OS 8.6 users have had their AppleShare Prep files modified and/or corrupted if those users were logged in to the server when it was restarted. The symptom is that if they had auto-logon enabled in the Chooser, they are asked to log on to each server TWICE, rather than once.

April 26, 2001
Mark Dudek

We have a Windows 2000 SP1 server cluster with a dozen Mac clients. Our server has never been rebooted and we have encountered similar problems. 

Most of the clients are using the Apple Standard UAMs while others are using the Microsoft's UAM to log onto the server. Some work stations have the volumes selected to mount at start up and some do not.

The problem will manifest itself in two ways.

1. When the users mount the volumes they are asked to log in twice. After logging a few times this way, they get an error message that the server can not be found.

2. When a volume is opened, a single folder on that volumes, for a moment, appears twice.

After successive log ins, the second, duplicate folder will persist and will only disappear when you try to open it. After a few more log ins, the Finder will crash every time that volume is opened.

Initially the problem was cured by throwing out the AppleShare pref file. After a week or two I needed to throw out the AppleShare pref file and Servers folder inside the System folder.

I am now encountering corrupt System Suitcases.

This is happening most often to the Macs that are running OS 8.51, but I have also encountered it with the 8.6 and 9.1.

Mac UAM authentication under Win 2000: insecure?

January 26, 2001
Brad Judy
Information Technology Services
University of Colorado at Boulder

When you enable Macintosh access to a Windows 2000 volume, you have three authentication options: open guest access (no password required), clear-text passwords (very bad network security), and UAM authentication (AKA Microsoft encryption). The last of these options is discussed on your site, but no one mentions that it uses LM authentication. LM authentication is the lowest (and easiest to crack) level of encryption supported by Windows 2000 (the other primary ones being Kerberos, NTLM v2, and NTLM v1). This presents a security problem for many sites. Many sites ( including my own) would like to disable LM authentication in our Windows 2000 domain, but cannot because of Macintosh UAM clients.

The higher education community is attempting to pressure Microsoft to release a Macintosh UAM client capable of using Kerberos or NTLM v2 (preferably Kerberos). There is the possibility of a third party creating a Kerberos Windows client for OS X (a work in progress), but not for OS 8.x/9.x.

Feel free to send [to Microsoft] messages of support for the effort to increase the security of Macintosh UAM clients.

Mac VPN connection over DSL PPPoE.

December 4, 2000 -- Sean M. Sloane wants to establish a VPN connection over DSL (to a Windows 2000 server), but with a Mac client instead of a Windows client, but without AirPort. He also needs to use PPPoE (PPP over Ethernet):

We have just setup a VPN server with Win2K. I would like to be able to connect from home. Fine, just get Tunnel Builder. The catch is that I also use Pacific Bell DSL with EnterNet 300. On NTS's site they say in the FAQs that EnterNet (PPPoE client) and NTS's TunnelBuilder (a VPN client, LTP2 protocol ) cannot reside or coexist on the same machine. They will, at some point, make TunnelBuilder support PPPoE but don't have a specific date for release.

We were wondering if another PPPoE solution, MacPoET would work, so we checked Wind River's MacPoET FAQ, which says that two VPN products have been tested with MacPoET:

• The IntraPort MacOS client that works with Compaq/Compatible System's IntraPort server.
• The AltaVista/Compaq MacOS client that worked with AltaVista's/Compaq's AltaVista/Compaq Tunnel product. (Sold to Axent, known as RaptorMobile EC.)

Based on this, it is conceivable that MacPoET may work with NTS's TunnelBuilder, but it hasn't been tested. If you've tested running MacPoET with TunnelBuilder, please let us know what you found.

In the next report below, a reader suggests using a home router.

February 15, 2001
John DeRosa
IT Desktop Solutions
Motorola, Inc

I read the [above] item at MacWindows and might have a more generic solution than finding a PPPoE/VPN combo client, albeit more costly (but with more features).

First, PPPoE is the devil's work and I wish it would just go away. Be that as it may, there are ways around Sean's dilemma.

The solution is to find a hardware device that will 1) pass his Macintosh VPN authentication and 2) do the PPPoE authentication also. That hardware device is a home router.

My choice is to purchase one of the many hardware firewall/routers on the market today from such companies as NexLand and LinkSys. More seem to appear on the scene every day. Besides performing the PPPoE authentication, an added benefits is that these routers protect your home LAN from hacker intrusion by the incorporation of firewall technology.

NOTE: Before you go out and spend $200 or so on a hardware router/firewall, contact the manufacturer and make sure that it will work with the VPN client you want to use. Now, all the devices on your LAN can safely utilize your single Internet DSL address without having to individually dance the PPPoE dance.

Problems with MS User Authentication Module 5.0.5 and changing passwords

On March 20, 2001, we reportedthat Microsoft has posted User Authentication Module (UAM) 5.0.7. Microsoft says the new version " fixes a bug that prevented Mac users from changing passwords over 7 characters long."

MacWindows readers reported a password bug with UAM 5.0.5, but not with previous versions. Here are the symptoms:

March 13, 2001
Stephen Chiang

Running UAM 5.0.5 on a PowerBook G3 Bronze, OS 9.0.4. When user tries to change his password, it will work, however if there are any numbers in his new password, I get an error dialog that says: "The Microsoft User Authentication method encountered an error, a misc. AFP error has occurred."

March 14, 2001
Brian Little

Same setup as your reported problem, but we are COMPLETELY unable to change passwords, numbers or not. We have been for months...We've come to rely on Outlook Web Access's password change facility almost exclusively.

Outlook Web Access will let you change your password via a secure server (we use Exchange for our campus mail system).

March 14, 2001
Jerry Colen:

Just wanted to let you know we have the same exact problem with UAM 5.0.5. When we try to change the password we get a "Miscellaneous AFP error".

March 16, 2001
Igor Zagatsky

We have the same problem ("Miscellaneous AFP error"). Highly annoying! This does not happen with UAM 5.0.4 that comes with Windows 2000, only with 5.0.5 that is on the MS Website. However the 5.0.5 version seems to be more reliable in general with the exception of the password problem. Sure would be nice if this would get fixed.

Still unable to change passwords on W2K using UAM 5.0.7.

March 23, 2001
John Lascurettes

I installed the UAM 5.0.7 and was unable to change my password. I get the following error:

The Microsoft User Authentication Method encountered an error. Unable to change password: your new password was not accepted by the server.

After sitting down with our lone IT administrator, we came to the following conclusions. Due to some pretty nasty hacker attacks we've had in the last year, only strong encryption is allowed by the Windows users in the office to change their passwords on the Windows 2000 server (Kerberos if I remember correctly). If the UAM is only using low-level LM authentication (as quoted by Brad Judy ), it isn't able to authenticate a new password because it isn't able to use an encryption level that is secure enough. Does this sound correct?

If it is correct, I'd be curious to know if anyone has any ideas for a work around without compromising the security required to change the password. For now, Mac users have been using a guest W2K station to log in and change their passwords. We have had hackers change the administrator password when permissions and security were set too low; so allowing LM authentication for changing passwords is not an option.

Theory: may be linked to security setting.

April 16, 2001
Brad Judy

I think I know the cause of the problem with changing passwords on a Win 2000 environment - it came up in an MS Focus security posting as an aside. I don't have time to test/verify this yet, but it appears that this is caused by setting the "Computer Configuration\Security Settings\ Local Policies\Security Options\Additional Restrictions for Anonymous Connections" to "No access without explicit anonymous permissions".

It can also cause a number of other problems as it is a very restrictive setting.

Here is the MS KC article that backs up my idea:

http://support.microsoft.com/support/kb/articles/Q246/2/61.ASP

It is related to authentication as originally thought, but not to the LM vs NTLMv1 vs NTLMv2 vs Kerberos fashion. It has to do with the level of allowed anonymous access. Here is the important piece of the article (see the fourth item):

• "The following tasks are restricted when the RestrictAnonymous registry value is set to 2 on a Windows 2000-based domain controller:
• Down-level member workstations or servers are not able to set up a netlogon secure channel.
• Down-level domain controllers in trusting domains are not be able to set up a netlogon secure channel.
• ***Microsoft Windows NT users are not able to change their passwords after they expire. Also, Macintosh users are not able to change their passwords at all.***
• The Browser service is not able to retrieve domain lists or server lists from backup browsers, master browsers or domain master browsers that are running on computers with the RestrictAnonymous registry value set to 2. Because of this, any program that relies on the Browser service does not function properly."

I still haven't tested in our domain (too many things going on now), but I think this solves the mystery.

April 24, 2001
Brian Little

In reference to the article [above], we've been fiddling with this setting on our servers, and I _was_ able to change my password using the 5.0.7 UAM after changing the setting as noted. But _only_ on our Win2K servers. I still can't change my PW when attempting a connection to our NT servers. The plot thickens...somewhat.    

TIP: How to add MS Server/UAM to Keychain.

March 19, 2001
John Lascurettes asked how to add a Windows server to the Mac OS 9 Keychain using the Microsoft UAM:

[I am] having a problem with Microsoft UAM 5.0.5 and Apple's Keychain. I am running OS 9.1 so I have the latest Appleshare software - but every time I mount a Windows 2000 Server volume, the "add to keychain" is grayed out.

I tried to add manually by taking the mounted directory and dragging to my keychain items window. That added an item to Keychain access, but when I try accessing that volume again, it accesses the keychain but still brings up the UAM dialog and requests my password.

Also, what was mounted was "volume B" which lives on "server A", but the keychain item is named "server A" in Keychain access.

March 20, 2001 -- A reader named Jim sent us a procedure for saving a MS UAM 5.0.5 password to the Mac OS 9 Keychain:

The Windows 2000 Server administrator needs to:

1. open Computer Management,
2. right click on Shared Folders,
3. select Configure file Server for Macintosh,
4. and check the "Allow workstations to save password" box.

August 1, 2001
Ethan Allen

Just letting you know that the password/keychain problems with the Mac UAM for Win2K were actually fixed months ago but you can't get the upgrade to this fix unless you buy Win XP when it comes out. It is a known issue though.

October 8, 2001
Dan Foshee

Our Win 2000 servers do not allow the Mac users here to add the individual shares on the servers to their Keychains. I downloaded and installed the 5.0.7 UAM, and per the March 20th, 2001 tip by Jim, had the Server Admin allow workstations to save passwords.

What I discovered was that mounting at startup is still not allowed by this logon method; however, the 'Add to Keychain' option is checkable, and basically adds the entire server to the keychain. I also discovered a way to have those individual shares mount at startup, although it does take a few extra steps.

1) Add the desired server to the Keychain and select the shares you want to be mounted at startup. Hit OK.

2) Make aliases of those shares and put them in the Servers folder of the System Folder.

I also rename the alias like this: share*server, example: Common*TYSONA. I don't believe it's necessary, but it's the way I noticed other aliases in the Server folder.

Changing passwords in Win2K domain from a Mac: Bug report and workaround

See also Microsoft Knowledge Base article Q328417:

June 11, 2001
Chris Kasper

I've had the following problem and there is a hotfix in development...to be released with SP3.

My environment uses Exchange 5.5 and Websense on a Windows 2000 domain. When my Mac users change passwords they can access file and print shares, but cant get exchange email or authenticate through our Websense proxy. They get the "Login failed" error. Additionally, If the same user then logs on to a Windows machine, they have to use the old password and lose the ability to get email, web authentication, and cant even change their password. This is a bug with the Windows 2000 implementation of SFM.

The only fix is to then reset the password from a Windows 2000 DC. A workaround for the whole password issue is to make your users change their passwords from a windows 2k pro station or a windows machine with the active directory client installed.

Mac username limits on a Windows 2000 protected share

July 11, 2001
Daniel Foshee

A hard lockup with a gray box if another share from that volume was already mounted. All are running OS 9.1, and have all the relevant firmware and software updates applied. As it turns out, all three users with the problem have 9 characters in their user name; the shortest password is 6 characters, with the other two having longer ones. We've also found out that if my PowerBook user has both the password-protected and the non-protected share set to mount on startup, it'll come up just fine, no lockup. I've set one of the B/W users to the same, and we'll see if that works.

We're using a Windows 2000 Server, SP1. Our NT guy--normally a non-biased Windows user, and generally pretty savvy--says this is a Mac OS limitation, but I find that hard to believe. I do know that our Mac users can't have a volume password larger than 8 characters, though, so maybe he's right.

I can log-on to the volume/server just fine, but when I try to get onto the protected share (again, assuming the unprotected share is mounted already) it will bring up the gray dialog box for me to put my password in, only with no text, field to put the password in, or buttons, and freezes the machine HARD.

Both users have permissions for the protected share, and they can log onto it from another desktop Mac in the dept. I can also do this from an "Emergency Disk" CD (that I burned from a desktop G4) on either machine.

It does this with either My Settings or Mac OS 9.1 Base Extensions, with AppleTalk on or off, Static IP or DHCP, or with File Sharing on or off.

I have already done these on both machines:

• Zapped the PRAM, both by "hand" and with TechTool Pro 3.0.3
• Ran TTP, NUM 5.0.3 and DiskWarrior 2.0.5
• Rebuilt Desktop ad nauseum
• Deleted AppleShare Prep files, TCP/IP, AppleTalk and Finder prefs
• Performed a partial, "non-clean" install of OS9.1
• Performed a clean install of OS9.1, deleting previous System Folder

  I do have a workaround: If I log-on to just the protected share without having the other share mounted, I can get on. I've NOT done a clean wipe of the hard drive and reinstalled everything; I'm prepared for it, but don't want to if I don't need to.

Issue with large file copies on Windows Servers: "File already exists"

This problem also appears to occur with Windows NT server, and with Windows clients as well. Readers below offer explanations and solutions.

August 17, 200
Steven Lugo

I am a Sr. systems Engineer for a large publishing company that has several Mac client on a windows NT domain with several Windows 2000 servers. The issue that I am having is that when a user on a Mac copies a large amount of data (100 meg) from one W2k server to another Win2K server he receives an error message half way through the copy that the file already exists in the location when in fact it does not. The files consist of font files and .tif files, but if you copy those files over one at a time they copy to the server.

August 30, 2001
Alan Daly

I've experienced a similar problem: copying numerous (1,000+) files from a Windows NT 4 server to a Mac client (OS 9.1) and receiving a file already exists message. My solution was the same as Steven's: copying in smaller batches.

August 30, 2001
Ed Joras suggests some workarounds:

We've seen this as well, including when NT 4 is in the mix. We've writting an AppleScript as well as used File Sync on the Mac to get around this, but both slow the process down.

August 30, 2001
Timothy Cheng sees the problem with Windows clients as well:

I have seen this problem [with Windows clients] as well. In fact, when I copy too many files, Windows will stop midway. I have a two step solution, both involving the command prompt:

1) xcopy
2) ftp

I never use the Windows Explorer to copy 'large' or 'many' (over a few hundred megs) files. It's not reliable enough.

However, Todd Miller, below, says that xcopy does not get around the problem.

August 30, 2001
Mike Maday found the problem with Windows clients and a Novell Server:

I've had the exact same problem when copying large amounts of files from an FPNW volume to anywhere else using Win 9x clients and Client32 for Novell. Internal API problem on Win 2000 server?

We have additional new reader reports on our Windows 2000 special report page. If you've seen this problem, please let us know.  

August 30, 2001
Todd Miller

I have been unable to duplicate the problem that Steven Lugo reported. We have a Windows 2000 Server running SP 2 and hotfix Q277862. The hotfix fixes the problem of filename changes not being visible to Macintoshes that are changed by Windows machines - and may fix the problem Steven reports. I do not have any Windows 2000 servers without the hotfix to try to repeat the error.

This is a test I have ran - (these are all MP3 files)

• Copy 10 files totaling 28M -- Successful
• Copy 20 files totaling 73M -- Successful
• Copy 30 files totaling 129.9M -- Successful
• Copy 1 files totaling 380.1M -- Successful
• Copy 89 files totaling 366.1M -- Successful

  I have found another bug, however that made me think that we were having the same problem. File names can cause a problem. To duplicate the problem I have found:

1. Create a new folder on a Windows 2000 server with SFM.
2. Copy a file named Microsoft.txt into the folder.
3. Copy a file named Micros~1.txt into the folder. -- This will generate an error that there is already a file named this and will not give the option to replace.
4. Copy a file named Microsoft Sucks.txt and this file will copy normally.
5. Copy a file named Micros~2.txt into the folder -- This will generate an error.

   I did this in an empty folder to ensure that Microsoft.txt would be the first Micros~1.txt in the 8.3 naming convention that Windows clings to. I would suggest that Mac users ensure that none of their files are named with this name shortening convention to avoid any possible conflicts.

   In speaking with our server admin, I discovered that this is a problem with Windows file copies too. This problem is repeatable using xcopy on a Windows box.

September 4, 2001
Brad Garlich

I've seen this same kind of issue when I copy over from a NT server to a Mac, usually a temporary partition for burning purposes.

Explanations and solutions:

September 4, 2001 -- A couple of readers have offered fixes for the problem with large file copies on Windows Servers. (This is where you get message saying that the file already exists.) Vickie Slaydon passed along causes and a Microsoft Knowledge Base article:

It has happened to us before. A couple of things can cause this:

1) If you have created Mac volumes at the root folder; or

2) If you have greater than 65000 files and folders on the volume, your index for the server volume gets out of whack. You can move the volumes down one level of folders from the root. You also need to stop/start the File Services for Macintosh, but before doing so, you must rebuild the root drive share INTENTIONALLY damaging the index for it to rebuild with the DIR command found in KB article 147909.

We note that having the Mac volume at the root volume causes a number of problems that we have previously reported (such as here for instance).

September 4, 2001
Dwayne Wescombe

The Windows NT and 2000 resource kits come with a utility called ROBOCOPY. This utility is useful for many things, including copy only new files and copying only files that have changed since a given date and time. Using this utility has several advantages:

1) I have never had it fail with large file transfers between the Mac and NT/2000 environment (except where a workstation was turned off)
2) If it does happen to fail for some external reason (e.g. Workstation gets turned off) then it will continue again at the first opportunity (e.g. next time the workstation is turned back on). This requires the correct switch combination.
3) You can create a log file of all files copied/failed. Using scripts this file can then be manipulated to give you a useful report.
4) It is as fast, if not faster, than copy and xcopy.

I never originate a copy of a large numbers of files (either to or from a Macintosh) from the Macintosh. It invariably fails at some point.

September 19, 2001
Bryce Steiner

I only see this problem of copying a large number of files to a Server when there is a file in use such as a font on a Mac being in Adobe Type Manager that is actually located on the Server (even if it is not in activated in ATM Deluxe) other than that it all works fine. Every weekend I back up about 26,000 files (30 GB) to another Win 2000 server using Explorer all started at the same time.

Mac OS 9.1 and 9.2.1 disconnecting from Windows 2000 Servers

This has been determined to be a problem with the Mac OS software affecting various AFP servers. You can find a discussion on our Mac OS 9 Special Report page.

Periodic disconnecting from Server

February 4, 2002
Don Begley

My OS X 10.1.2 machines disconnect from the network after about 15 minutes of inactivity. Same machines on OS 9 run all day long. I wonder if these aren't related problems. My configuration: Windows 2000 Small Biz Edn w/2 G4s and many Win machines of various OS flavors.

Another quirk is that Windows 2000 is very sensitive to the time on its client machines. (I understand it's used to establish machine identity.) If an XP client in particular does not have it's time synchronized to the server, the server cannot access the client. I wonder if there could be a time-related issue going on between Windows 2000 and the Macs, too.

February 5, 2002 -- Several readers responded to yesterday's report of a reader who keeps getting disconnected from a Windows 2000 Server. All said this was a setting on the server. Dennis Wallace describes how to change this setting:

The reason for this is the internal security parameters of Win2K are set to disconnect inactive clients after 15 minutes. To change this, go to the Administrative Tools, and select Local Security Policy. The relevant setting is in Local Policies/Security Options. Set the "Amount of idle time required before disconnecting session" to 0 to prevent disconnects.

February 18, 2002
Jeff Chambers is also seeing Macs disconnecting from Windows 2000 Server, but when the Mac sleeps:

Both Mac OS 10.1.2 machines are running nothing special except that both will disconnect from shared volumes from two different servers. One is UShare for Solaris and the other is Windows 2000 Server SP2

I have fixed the problem by setting the energy setting to never sleep and that has solved this problem for both machines. The screen saver still works though. I have also seem it affect another network program with similar disconnect results.

Apple Menu Options problem--and workarounds--with Win Server SP2

October 2, 2001 -- Joerg Erdei sent this report of a problem and workarounds with Windows 2000 Server:

I just finished troubleshooting a strange problem when users could not rename files (folders are fine!) on a certain file server from within certain Macs. Saving to and deleting from the server, and changing file content works. It turned out that this only occurs in a specific client/server situation:

Server affected:

Windows 2000 Server SP2 only (2000 Server & 2000 Server SP1 do not have that problem)

Client affected:

Mac OS 9.1 (see 'Details')

Workarounds:

1) Disable Apple Menu Option in Extension Manager
2) Replace Apple Menu Options with a newer (v1.1.9) or older (v1.1.7) version

Details:

The problem is with Apple Menu Options 1.1.8, independently from its settings. This version is only included with Mac OS 9.1 so other Mac OS versions are fine. I did some testing on what combinations of Apple Menu Options and Mac OS do have that problem:

Apple Menu Option	1.1.7	1.1.8	1.1.9
MacOS 9.0.x	OK	Problem	Problem
9.1	OK	Problem	OK
9.2.x	OK	Problem	OK

Erdei later determined that this problem is caused by a conflict with Trend Micro ServerProtect, which also causes a -5006 error when users try to empty the Trash. (See Erdei's report below.)

Word 2001 file corruption

Please see this item on our NT Unsolved Mysteries page.

-5006 error when users attempt to empty Trash containing server files

Readers have reported this a problem which prevents users from deleting folders on NT Server and Windows 2000 Services for Macintosh. Several readers blame Trend Micro's ServerProtect virus protection software for the problem.

Problem:

February 7, 2000
Shyam Nathan

We are running NT Server 4.0/SP5 with about 20 Macs. when trying to delete folders on the RAID, we get a message: "You can not move 'folder name' to the trash because an error of type -5006 occurred."

The RAID was near full capacity, then we archived about 12 gig (the RAID can hold approx. 42 gig). I get the error message from where ever I am on the network, including the server.

November 9, 2001
Dieter Gohl

For the past few days we have been getting error -5006 (afpDenyConflict AFP Deny conflict) on some WinNT4SP6 and Win2000 SR2 Servers. Sometimes we cannot rename or erase files on the Servervolumes. No matter witch user - also the admin-login is affected. Connect the NT4-Server with MSIP - no problem. This is a solution for NT4 but I'm sill in search of a solution for Win 2000.

Cause:

November 15, 2001
Dieter Gohl

I figure out what the problem is in our case. The errors will be caused by TrendMicro ServerProtect. After stopping the two services on the servers all works fine. I pose a question to the support of our Trend Micro distributor and they told me that Macintosh are not supported by TrendMicro ServerProtect.

November 15, 2001
Drew Robertson

Found the cause to the Error -5006 problem. We are running Trend Micro's Server Protect. The antivirus software automatically upgrades itself from the Internet. Scan Engine 5.5 and above cause the problem.

I have no clout with Trend Micro so I doubt a fix will be out any time. I should also point out that Ryan Powell with Premiere Conferencing put forth great efforts to find the problem. Everything pointed to Trend when he and I discovered it was our only similarity outside Windows 2000 SP2.

Possible fix

November 19, 2001
Ken Truesdale

I too was experiencing the 5,006 error when trying to delete files from our Win2K server. We also have TrendMicro Server Protect installed. I contacted Trend Micro and after working the problem for a bit, they provided a new scan engine (version 5.63). Initial tests show that this has fixed the problem.

November 19, 2001
Joerg Erdei confirms that the Trend Micro ServerProtect is the cause of not only this problem another posted at MacWindows as well:

I can confirm that Trend Micro ServerProtect is the culprit. It is the cause of error -5006 (and -1805) as well as of the problem I posted back in October ('Apple Menu Options problem--and workarounds--with Win Server SP2. October 2, 2001').

It does not affect Windows 2000 SP1 Server (well, not in this respect, but realtime scanning option enabled triggers some real nasty and unacceptable slowdowns in SFM)! With SP2 the problems you see depend on Mac OS version and Apple Menu Option presence and version (see October 2 posting and table below). There is no longer a workaround on the Mac part for a server with up to date security updates + current Trend scan engine (5.600). Deinstalling a few security updates on the server did not change the situation and I do not tend to do more testing in that direction. Only workaround is to disable Trend ServerProtect realtime scanning (or to stop 'Trend ServerProtect' service on the affected machine at all).

As to the version of Trend scan engine I did testing and workaround in my previous posting with engine 5.480. The Apple Menu Option workaround was most likely still valid with engine 5.550. With scan engine 5.600 and several additional Win 2000 security updates the workaround has lost its magic.

In the table below I list the dominating behavior(s). Sometimes out of nothing an action does work once or twice. Server is Windows 2000 SP2 with all critical and advanced security updates up to August 19, 2001, and Internet Explorer 6, Trend Micro scan engine 5.600.

Mac OS	9.0.4	9.x	9.1	9.1	9.1	9.2.1
Apple Menu Option	1.1.7	none	1.1.7	1.1.8	1.1.9	1.1.9
create file&folder	+	+	+	+	+	+
rename folder	+	+	+	+	+	+
rename file	-	+	+/-	-	-	+
trash folder w/o file	+	+	+	+	+	+
trash folder w/ file	-/(2)	+	-	-	-	+
trash file	-	-	-	-	-	-
move folder	+/-	+	+	+	+	+
move file	+	-	-	-	-	-
change file (3)	+	-	-	-	-	-/+
move-replace folder	-/(2)	+	+/-/(2)	-	-	+
move-replace file	+/-/(1)	(1)/-	+/-/(1)	-	-	+/-/(1)
copy-replace folder	-/(2)	+	+/-/(2)	-	-	+
copy-replace file	-	+	+/-	+	-	+

+ works
- does not work, error -5006 (and additional error -1805 on not replacing a folder) or w/o error (rename file)

(1) deletes target file, but does not move/copy.
(2) deletes some files in target folder
(3) "This disk may be full or locked, or the file may be locked"

November 26, 2001
Joerg Erdei

I just have upgraded a Win 2000 SP1 server that has no problems to SP2 only (that is: w/o any additional updates). The -5006 problem immediately appeared on that one when realtime scanning of TrendMicro ServerProtect (v5.31) is enabled, so I can excluded any security updates, IE 6.0, etc as part of the problem.

As to Ken Truestale reporting the problem being fixed with v5.63, I cannot comment on this for according to TrendMicro ServerProtect Management Console, v5.31 is the most recent one. Also TrendMicro web and ftp site do not know of anything more current.

November 27, 2000
Ken Truesdale clarifies the issue:

The Trend Micro Server Protect Scan Engine for NT has a version 5.63. This should not be confused with the version number for the Management console which is at 5.31 (I wasn't clear on that in my original post).

I received the updated scan engine directly from their support staff, so it may not yet be posted. I'm sure if you call in, they'll forward it to you.

Long delay in Win SFM logon

The first reports of this problem were when the OS 9 Multiple Users was being used. Other readers report the problem with Multiple Users. The fix seems to be to delete the aliases in the System:Server folder on the Mac, as described below.

November 28, 2001
Kyle Crawford

We are trying to use multiple users to implement some basic access security, but we are having trouble connecting to a Windows 2000 server running Services for Macintosh.

We get a very long delay when trying to connect to the server when logged in as any user except the owner. The Mac appears to be frozen for 7 minutes or so, but eventually the server volume will mount.

This does not occur when using an Apple server, but that is not an option for us until Apple releases some real server hardware. It is similar to an issue with the Microsoft UAM in your Window 2000 report, but we get a long delay and then the volume mounts.

Suggestions

December 3, 2001
Mike Brady

John, this is a little off what you want, as it's probably a slightly alternative approach to Kyle's problem, but we have been using Multiple Users together with a Windows 2000 server running SFM for some time now (and we were using NT server before that). We use Multiple Users on Mac OS 9.1 and 9.2.1 set up to allow only local users - of whom there are only two, "Admin" and "User" to log on. The "user" has limited privileges. When a "user" attempts to log on to Multiple Users, a custom program displays a login dialog (picture attached), gets a name and password from the user and validates it by trying to mount the volume, on a W2K Server volume, that contains the user's personal folder. If successful, the desktop and Documents folder on the Mac are cleaned up, an alias to the user's personal folder is put on the desktop and the volume it is on is also mounted. Finally the user gets access to the machine.

Readers point to aliases as the cause of the problem

December 3, 2001
Tim Mallon

Tell Kyle Crawford to double check his System Folder / Server Folder, and to make sure he doesn't have any "old server / share" alias in there. This will cause very long mounts, i.e. the Mac spins it's wheels looking for something that it's there. It could take several minutes before the Mac gives up, and moves on.

David Stone
December 5, 2001

Mac systems newer than sys 8.6 have a new AppleTalk client that saves options for connecting to servers at startup as alias's in the servers folder of the system.

I have found on all Win NT systems that connections form Mac clients to the same server duplicate so that some workstations have upwards of 40 alias's to the same server. Each of theses alias's try to resolve on startup - hence the slow down. This effects single and multi user Mac setups! The solution is to periodically delete theses alias's.

Victor Wise
December 5, 2001

I've seen this problem before especially after a move where there are a number of alias's in the Recent Server folder. It seems the MacOS is trying to verify each of those servers and it takes a while for it to time out. If they check their recent servers folder for unused/old shares it may speed up log in.\

December 6, 2001
Dan Schwartz (of the Mac-NT list) found a utility that helps:

A quick solution to "Multiuser Macs login delay problem with Win server" is the Freeware "Empty Servers Now!" Just be *Sure* to use the "skip" feature for the original alias.

December 12, 2001 -- Gil Davis reports having long delays with Macs logging on to Windows 2000 servers, but without using the Multiple Users feature of OS 9, as was previously reported. Davis also verifies that the problem is cleared up when deleting the aliases in the System:Servers folder.

Another solution and explanation

July 12, 2002
Stephen Pruitt

For MacOS 9 and Windows 2000 server we have deleted the "Servers" folder and created a text file (Simple Text) named "Servers" and placed it into the System folder and locked the file. This prevents anyone from setting a share volume to auto mount.

This is desirable in our production environment with many different operators who often select the check box to have the volume auto mount, sometimes with their personal logon.

Two other points: Each AppleTalk volume is referenced by a simple indexing method on the Macintosh. When AppleTalk volumes are added or deleted on the server the index gets out of whack and the Apple share Prep preference must be deleted so that the index gets recreated. Otherwise, when you access a volume, you don't get the volume you expected. Also, some applications auto mount volumes (i.e. Suitcase), when those applications and the aliases inside the Servers folder of the System folder try to access the same volume the machine may get hung.

Delays in logon to Windows 2000 Server

February 6, 2002
ulian Beckett

I'm having problems with Macs OS 8.6 to OS 9 logging onto a Windows 2000 server. Every time the Mac user inputs a username and password (which is accepted), the log on screen reappears. This can be canceled again and again until it eventually disappears, the server mounts and work continues as normal.

Suggestions for a fix

February 7, 2002
Grã Downey

I have seen similar logon loop issues on the networks I manage. The following solutions have worked for me:

1) Open System Folder:Servers

- if multiple aliases for your server exist, delete them and all should be well for a while. For some reason multiple copies sprout up over time. I've heard of some folks getting fed up enough to create an Apple script to empty this directory upon shutdown. If the problem persists, you might want to try this approach.

2) If the above doesn't help, this also works if you have a user mistakenly check the Chooser box to logon at startup, then open System Folder:Preferences -- delete the AppleShare Prep file. This gets rid of anything cached relating to AppleShare logons.

February 8, 2002
Stefan Reumann

1. Open the System Folder:Server
2. Delete all Aliases
3. Go to the extensions manager in Control panels and disable keychain
4. Reconnect to the server(s)

   I am not sute if this solves the problem for 100% - deleting the aliases every once in a while DEFINETLY helps.

The interesting thing is that its the same fix for the problem of long logon times, described above.

Server alias not mounting after Win Server Crash: Keychain at fault?

December 7, 2001 -- Marty Czachor reports the following problem after his server crashed:

Each of 40+ Macs connects to three NT/2000 Servers, and each server has a single volume. We connect using AFP over TCP-IP. Each system (Servers included) are assigned static IP addresses. We have also turned OFF the AppleTalk protocol on each NT/2000 Server.

Had an electrician working on our APC Symmetra Power Array. Accidentally killed it, and every system in our office, including our network switches, crashed immediately. When power was restored, our Macs were not able to automount these server volumes. For each Mac, the username and password were successfully stored in the Keychain. And the Keychain is the first thing opened upon system startup. (We use Keychain AutoUnlock v1.2)

We had left alias's to these three servers' volumes on each Macs' Desktop. Upon startup, the user would click to open these server volumes. It should lookup the username and password from the keychain, and this had always worked in the past. But NOT today. (Actually we use KA v1.2, but it does this step automatically, and failed as well)

Instead of automatically mounting these volumes, each system displayed the "standard AppleShare Login Screen". It's like there was NO matching entry in the Keychain (but there was).

It almost seems like my network was somehow being ID'd differently.

To solve this problem, I had to manually mount each servers' volume, and then repenter this servers' volume into the keychain with the same username and password that used to work. And that solves the problem, but there's got to be a better way.

December 12, 2001
Marty Czachor

I seem to be able to to be able to "more narrowly" define this issue. Seems to be an issue in the Keychain. After the entire network crashed, the alias to the file server's volume DOES connect to the server bringing up the standard "Log in" screen. But the issue seems to be with the Keychain not returning the "Saved password", so automatic log-in cannot occur. Even though the password entry is still in the Keychain.

(And the keychain was automatically unlocked at system startup using Keychain AutoUnlock).

If you've seen this problem, please let us know.

Possible Explanation:

December 13, 2001
Simon Boyle

Regarding the Server alias not mounting after Win Server Crash, this has been the case with aliases to NT4 SFM volumes ever since the service pack that caused NT to recreate/reindex each volume after a reboot. The aliases don't work because the volumes receive new IDs. I'm fairly sure that I originally learnt this from MacWindows...

Using Windows 2000, if the aliases refer to TCP/IP mounted volumes, things work (not to mention the benefits of faster file copying, less network chatter, and better error handling of stalled services on the Mac end).

We may already have this information somewhere at MacWindows, as Boyle says, though we haven't been able to locate it.

December 13, 2001
Marty Czachor provides more information about his situation:

I saw a response from someone, and want to clarify our network environment. We are using NT 2000 Servers, Mac ALWAYS connect using TCP/IP. We have actually unloaded the AppleTalk protocol.

The aliases do connect to these servers. But the aliases do NOT find their password stored in the keychain. All our Macs are running OS 9.04 or 9.1.

Still hope someone can shed some light. I am going to explore "Volume Mounter 3" that was just described on your site.

Win Server files appear in trash cans of Macs--sign of a virus?

May 24, 2002 -- Jo Vanstraelen is having a problem with files on Windows 2000 Server appearing in the Mac Trash:

Suddenly appear files in the trashcan's of the Macs. The files are unable to delete on the Mac so we've to reboot the mac in order to show the trashcan's properly. The files come from the WIN 2000 Server.

I think it is a filesharing problem on the server. The networktrashfolders get mixed with eachother. Because one mac user gets the trash can from another user.

Before the problem arose, we used a decalpha server with no problems. Meanwhile we've upgraded to the new server, to mac OS 9.2 and to gigabit network switches. I'm looking for solution according the following problem.

The environment (prepress):

20 Macs (G3 bow, beige / G4) and 15 PCs (WIN NT 4 wks)
2 Scitex Brusque servers, 2 Enterprise 450, 3000 server
WIN 2000 Server

All Macs are using OS 9.2.2
All PC are using WINTEL SP6

May 28, 2002
Arnoud Helmantel

I think it is quite likely that one of the PC workstations connected to the server is infected by a virus. I don't remember the name of the specific virus (nimda? badtrans?) but a virus appeared a few months back where the virus would put a file with the .EML extension in every folder it finds, including the hidden 'Network Trash #x' folders on the server. I would recommend to scan the workstations for viruses.

May 29, 2002
Dave Heap

I would like to confirm this. We had a nimda virus attack some months ago and it writes files with tantalizing (to some) sounding names (with a .EML extension) in any open network shares it can find. Unfortunately the NT4/Win2K hidden 'Network Trash #x' folders on an NT4/Win2K server running Services For Macintosh are set wide open by SFM, and so collect myriads of these files. It is not easy/feasible (I did look into it but can't remember the details) to change this permissions situation, so they remain there as a honey pot for nimda files. Fortunately their location reduces the risk of them being activated.

July 15, 2002
Jo Vanstraelen

We're working with the a Win 2000 Server with 30 Macs. We also experience the problem that suddenly some Trash cans contain files which were deleted even month's ago.

I looked in the the networktrashfolders on the Win 2000 and for some reason some files and folders reappeared. For an instant I thought it could be the backup system (backup exec) that restored the contents of the trash folders but none of the folders were checked for restore.

We also have files and folders which disappear for some reason but that could be a problem of its own.

Win 2000 "-54 file is locked error"

June 29 , 2002
Jane Vorhies

Last weekend, we moved a Mac user's data(4.12gb) from a NT server to a W2K server, and started having problems with Quark. Our problem sounds exactly one mention in your archives: the Mac user can open a Quark file, modify the files, and save the changes once without any problems, however, if they try to modify this file again, they get a "File is locked [-54]" error. At least, they can do a 'save as...' , and name it something else.

Unfortunately, this problem seems to have trickled down to other Quark files that were already on the server before the moving of the 4.12 gb of data. As a side note, if one of these Quark files is opened with Quark for Windows, and modified and saved multiple times - it works just fine.

Here is a bit more background information. The file server we copied the 4.12gb of data to is attached to a Dell SAN. We have copied the 4.12gb of data to another W2K server (no SAN and no existing Quark files), and no errors are produced by the Mac user making changes.

We have applied the 'DisableCatsearch=1" fix in the registry, and rebooted the server - but the problem still persists. Any other suggestions?

July 15, 2002
Tobias Hall says that the cause of the problem is virus projection software on the server:

We had a similar problem where the server suddenly reported that the files could not be replaced or deleted saying they they already existed or was in use.

If a file was saved to hard drive, renamed there was no problem putting it back but if it was only modified the notification would come up.

The problem was caused by the Virus checking application on the server. After first turning it off we discovered that the problem disappeared. We changed the Virus application from Trend to Network associates and the problem went away.

Word 2001 on OS 9.2.2 causing continuos network traffic to Win servers

July 15, 2002
Mark Read reports that after installing Word 2001 on Mac OS 9.2.2 on several Macs, there was a continuous stream of communications with mounted Windows NT 4 and 2000 servers:

I've just closed of a problem with the Microsoft Australia team that you and your readers should be aware of.

After installing Word 2001 on all of our new G4 Quicksilver and flat-panel iMacs (running system 9.2.2), I noticed that 30+ page documents that were opened from our NT4 file server continued to communicate with the server, even though the client computer hadn't been touched for over 5 minutes. These documents are less than 500 Kb each.

When I tried to replicate the same problem with our Windows 2000 file server via both AppleTalk and TCP/IP connections, the same event occurred. We are talking about a continuos stream of data sent to the server/s, but the hard drive don't appear to write any data.

A Cisco certified engineer tested our network and reported zero faults. Even Microsoft stated that our test files showed zero network faults. My tests show around 480 frames per second. Each frame appeared to be between 40 and 312 bytes. (Consider what 30 or 1000 clients would do to the network.)

Whilst the case was open for 3 weeks with the Microsoft Australia team, I recorded data off our Windows 2000 server and sent it to them several times. They then forwarded it to their development team in the U.S. The development team recently replied and stated that this was a function of Word 2001 and that there was no work around.

In my personal opinion this is a major bug. Microsoft Australia's response was that this was also a bug, but there are no plans to fix it. I then requested that at least a knowledge base article be written concerning it, but suspect that one won't be and am therefore informing yourself and your readers. I can only hope that our pressure can force Microsoft to correct this problem.

Please note that Microsoft has also stated that this occurs with the Word for X on system 10.1.5. My informal testing shows that it also occurs.

July 17, 2002
Michael Curtis

I have seen this before, even under Office '98. I found it was caused by the "recently used files" option. When I turned this off all the network traffic went away.

July 23, 2002
Mark Read

This problem is NOT fixed by the "workaround" [of July 17]

July 24, 2002
Paul Gorski

I've been experiencing the same problem for six months, just after server permissions were changed on the Mac volume on our NT 4 server. In addition to the network activity, Word is creating, but not deleting, invisible temporary Word Work files in the directory of the open file.

Selecting files to open from Word's own recent documents actually opens the temporary files, leading to all sorts of data loss. There have been similar problems reported in Word, but usually only in regards to local files on local workstations, and not networked documents.

The network activity increases with the increased number of improperly closed/deleted Word Work files. Some users have Norton antivirus examining all activity and or opened files, only complicating the issue. (Increasing traffic as NAV examines these open files on the server.)

I've found that the Read/Write access to the Mac volume and the subfolders does not match. (Get Info...Sharing reports No WRITE access to the Mac volume, even we can actually Write to it.) And just this evening we are trying to resolve this problem. I will let you know how it comes out.

If I mount the NT 4 server volumes with DAVE and open the Word files through that connection, network activity is light, and no problem with temporary files occurs.

Also, if I mount the Mac volume on the NT 4 server through MacOS X 10.1.15 and open the Word documents through Word 2001 and Classic 9.2.2, the problems do not occur.

Leads me to believe there is a problem with the AppleShare client for MacOS 9.x with the NT/2000 server.

Problems with Service Pack 3

Service Pack 3 prevents Windows 2000 from booting

Numerous readers have reported this with Widows 2000 running in Virtual PC, while other report it occuring on real PCs. Readers report an error message "msgina.dll failed to load." The problem is not universal. There are some workarounds. Since the first reports of this problem occured with Virtual PC, our reports on the issue are on our Virtual PC 5 Reports page.

Mac OS 9 clients hang with Win 2000 Server upgrade to SP3--MS UAM may be the problem

August 6, 2002
Albert Mowatt

I have a Mac/PC shop. After upgrading to SP3 over the weekend I had my production department watch for problems. Half are running 9.2.1, the other half are running 9.2.2. The people on 9.2.1 are hanging and freezing mostly in Quark (4.11) and the people in 9.2.2 are hanging and freezing mostly in Photoshop (5.5) but the problems are shared in-between them. I know SP3 applied the permissioning hotfix see [Q320215 -Mac Permission explained-MSKB ] and I have found permissioning to be a problem.

August 22, 2002
Albert Mowatt

After struggling with this problem I have found what seems to be a work around solution. The Mac's in question all were using the Microsoft UAM. I had them stop using it and return to the Apple version. Lo and behold they stopped crashing/ but they occasionally froze.

The current MS UAM can be found here, I have not tested it yet. I am hoping that will fix the problem, it defiantly a SP3 problem. My other servers with SP2 are working in perfect shape.

August 26, 2002
Albert Mowatt

I have tested the Microsoft UAM 5.0.5 and this has indeed solved the problem of all slowdowns and hangs under OS 9. It is the newest UAM as of his email one located on the Microsoft page. Many of them say 5.0 but you must use Get Info to differentiate them and then use current one to be sure the fix will work. I believe this problem as solved.

Mac clients work with Win server, PC clients don't

October 7, 2002
Joseph Martino

I have a Win 2K SP3 running Mac file sharing. Sometimes when I share out a folder my Windows 98 machines can't see the folder under the server name but the Macs can see the folder no problem. It get better results if I do a start run //ntserver/file I can see the folder. Some of the folders both computers can see.

October 16, 2002
Jeffrey Dodds

I have a Win 2K SP3 running Mac file sharing. Sometimes when I share out a folder my Windows 98 machines can't see the folder under the server name but the Macs can see the folder no problem. It get better results if I do a start run //ntserver/file I can see the folder. Some of the folders both computers can see.

I ran into the same problem, check to make sure there are no spaces or special characters in the PC share name, AFP is very lenient but SMB is not on older versions of windows (ie...Windows 98).

October 18, 2002
Darren Montjar

Windows 98 has a problem seeing shares longer than 8 characters in name. He may want to double-check that.

October 18, 2002
Michael Hasse

If the Win 98 users wait about 15-20 minutes the missing shares will show up. Win 9x is notoriously bad about updating network info.

Problem with Windows 2000 NTFS and files embedded with EPS logos.

October 16, 2002
Marvin Van Stralendorff

We have come across a problem where one of our clients were using Word documents with embedded logos in EPS format. These files were stored on a Windows 2000 server/NTFS file system.

These docs open up fine, but when the client tries to edit and save changes to the same location on the server, it would come up with an error where it could not be saved back to the server (even under a different filename).

One way around it was to save the file locally on the client's HD (which happen to be a FAT32 file system) and then manually copy it back to the server.

I tested the same procedure above but removed the EPS logo from the doc and it all worked OK - that's how I knew this problem was related to EPS format.

I suggested to the client to use a different file format for their embedded logo in their docs as the EPS logo was making the doc a lot bigger in size (2-4 MB each) which is very inconvenient when emailing these docs to their customers.

Anyhow - after they had their logo changed to a different format - it all is working fine now, although they had quite a few docs to change! (But at least the problem was resolved which was the main issue.)

October 24, 2002
Bruce Butterfield

We get the same problem an both our Windows 2000 NTFS servers. It appeared after upgrading to SP3, and we started using Illustrator 10.

Solution for Illustrator

February 7, 2003
Patrick Marechal

Adobe has an update 10.03 for Illustrator to fix this bug. It's described in the readme file.

If you've seen this problem, please let us know.

Can't copy to Win 2k Server--"zero k available."

This problem seems to occur with SMB and AFP Services for Macintosh, but not ExtremeZ-IP.

March 31, 2003 --Jeffrey Pascone reports having a problem we reported last fall. He tries to copy files to his Windows 2000 Server, but Mac OS X tells him that there's no room (0k available).

April 4, 2003
Garry Swanson

Funny thing about this, I saw it today for the first time! A friend at work just bought a tiBook. We connect to our Win 2000 server using smb. The server connects, but shows that there is zero K available. Would be interested in how people get around it.

April 4, 2003
Shawn Hinkle says replacing SFM with Group Logic's on the Windows server fixed the problem:

I saw this also, it was before we moved to ExtremeZ-IP, it seemed to be that there were too many files on the volume for SFM to handle...

We would like to add that perhaps the problem is related to a large number of folders (as well as files) on the server.

If you've seen this problem, please let us know.

Invisible Quark files on Win 2000 Server

May 20, 2003
Glenn Roscoe

We recently moved from NT server to Win 2000 server. We run over 100 MAC stations plus printers.

We are now experiencing invisible quark files, invisible image files. All these files need to be moved at the server level to a temp folder then back into its original folder--then the Macs can see the files. We are also experiencing corrupted Quark files that start out fine, but then generate a "Bad File Format" error. We run Markztools utility and find a few images are flagged as modified, but they aren't. Once these images are removed the files can be repaired.

If you've seen this problem, please let us know.

May 22, 2003
Chris Rugen

I was browsing your site's front page, and saw an entry that sounds somewhat similar to ones we're having. We are plagued by inexplicable difficulties with our eight OS X 10.2.5 Quicksilvers and our Win NT 4.0 SMB server.

Some of the problems:

- Markzware's FlightCheck Collect collects our Quark files, and creates a problem where the collected fonts and images folders cannot be copied to the server in one drag, but have to be pulled over piece by piece. The error:

The operation cannot be completed because one or more required items cannot be found. (Error Code -43)

There are no illegal characters or unusual filename lengths involved.

- Quark files occasionally generate a "Bad File Format" error and are unopenable, even back on our OS 9 machine.

- Illustrator 10 cannot open a file from the server, change it, save, then open it again and save other changes. The file has an "unexpected end of file" error and cannot be saved. The contents then need to be copied out.

- Entire folders will become invisible to one user, but perfectly visible to another. (We've attempted to solve this problem by 'resetting' all of the user profiles/ rights in the group. We'll see if the problem occurs again.)

None of these things were a problem in OS 9. In fact, we could work off of the servers seamlessly (even if that's not the best method). This may or may not be related to issues described in the post "Invisible Quark files on Win 2000 Server. May 20, 2003" on your site. Also, I believe this may actually be 2 problems: one with FC Collect, and one with our server or related settings.

I updated to 10.2.6, which didn't solve our FC Collect problems.

If you've seen these problems, please let us know.

September 24, 2003
Bart Scholten

We are a publishing company with a W2000 SP3 file server connected to a SAN solution. Recently we have also seen the problem of invisible Quark files and thanks to your site, we were able to resolve the issue quickly by moving the file to root and back into the folder again.

We are planning a SP4 upgrade to try to resolve some other issues, which we have also seen, like file corruption and randomly locked files.

Workaround

April 11, 2005 --Derek Tom describes a problem with Windows 2000 Services for Mac that we've described before, one where files and folders become invisibile. He also has a workaround.

We recently discovered a bug with Windows 2000 Server's 'Services for Macintosh' (SFM) that causes some files and folders to disappear - actually, to become invisible (Mac file invisible flag enabled). In our case, the files/folders are only visible when on an Mac OS X machine, doing a Find File (command-f) and searching on the server for just invisible items (Visibility > invisible items). From the search results listing we can then copy the files to the local Mac OS X machine. Actually, in one case the copied files are visible in the Finder on the local machine but in another case the copied files are not, but are "seen" using Terminal and the command-line interface. In our case, the files are not visible on the Windows server in Explorer but Backup Exec does seem to backup the files even if they are not visible.

The problem is mentioned at the Mac Night Owl Message Board, Windows 2000 Mac Support Forum.

I believe the steps mentioned here should provide a temporary fix (although I have not tried them yet): http://support.microsoft.com/kb/q147909/

I figure Mac file utilities such as XRay, FileShaper, and A Better Finder Attributes will help to set the invisible flag back correctly.

Our server is running the latest version of Windows 2000 Server (SP4 with latest patches). Web forum link above suggested that the problem also exists with Windows Server 2003 too.

We never had this problem for years when running Windows NT Server 4.x.

Has anyone else encountered this or have a permanent fix? I would appreciate if some of you can try searching on your Windows server-based Mac volumes for invisible files and report back if you also have the problem. The search process can take very long and you can ignore the normal invisible files such as .DS_Store, Thumbs.db, .._<filename>, .Trashes, Icon, and ~WRLxxxx.tmp, of course. Sort search results on Size and Kind to try and find any improperly invisible files/folders. We have two Windows 2000 servers with SFM and both had a dozen or so folders and files that were invisible (one of them was an important job folder).

Am investigating a more permanent solution and am considering the following:

1. Apple Xserve

2. Windows Server 2003 with ExtremeZ-IP

Apple's solution seems to be a lot more expensive, especially when you add in hardware RAID (SATA and not even 10-15K rpm U320 SCSI HDDs!), a tape backup solution, and AppleCare Premium Service and Support.

If you'd like to comment please let us know.

Quark Files Corrupting

June 11, 2003
Jason

I just read your article dated May 20th [above] about Quark files getting corrupted when placed on a Windows 2000 Server. It turns out that all my Quark files that I stored on my Windows 2000 Server are now useless. Also, some of my old Photoshop files are corrupted too.

I am running Jaguar 10.2.6 and connect to my server via SMB.

The May 20 article Jason refers to reports an issue with Quark files becoming invisible. We also have numerous older reports of SMB file corruption with earlier versions of Jaguar.

June 12, 2003
Scott Schubert

Jason had called me regarding this problem. I suspect that the problem is related to SMB and Windows. I run a mixed OS network and have had no corruption issues with SMB from a Linux server. I suggested to Jason that he set up FTP server on his Windows machine and use Fetch or a similar ftp client to move the files back and forth. Another possible work around is to set up an NFS mount point on his windows server and connect to that.

June 12, 2003
Steve Fair reports that the problem does not occur with Group Logic's ExtremeZ-IP running on the server:

We are a large printing company and we store thousands of Quark files on Win2K server, SP3 running ExtremeZ-IP 2.5 with no problems. I am currently running OS 10.2.6 in a production environment on a small number of Macs with none of the symptoms described by Jason.

June 12, 2003
Bryce had a problem caused by StuffIt:

We had corrupt Quark files if we would decompress them with Stuffit while the stuffed files were on the Win2K server. I upgraded to the latest Stuffit Expander on OS X 2.6. That fixed our Quark problem. We connect with AFP/IP.

If you've seen these problems, please let us know.

Problem with Windows 2000 Server permissions

Problem:

May 22, 2003
Stephen Chiang

I'm running Services for Macintosh on a Win 2K server with SP3. I started noticing this problem on two separate servers since I started tightening NTFS security on my servers, basically removing the Everyone group and giving access only to those groups that need access.

Here's what's happening:

I create a SFM share point called MAC SHARE. I give permissions only to these two groups: DOMAIN ADMIN and CREATIVE. When a user of the CREATIVE group logs in via MSUAM or Apple UAM on either Mac OS 9 or X and creates a new folder within MAC SHARE, the CREATIVE group does not have access to this new folder. In addition, it looks like Everyone group is added into NTFS permissions for this new folder with nothing checked in the allow box, SYSTEM is added as well with everything checked, and the user is now the owner. If the user logs in via SMB on OS X, everything works as advertised (CREATIVE and DOMAIN are the only ones with permission to this new folder).

Suggestions:

June 2, 2003
B. C. Morris

I am working on this problem right now. We ran into a problem where all our NTFS permissions were reset. After that problem was fixed we started having inherited permissions problems with Mac OS created folders on the Server.

First, according to Microsoft, for SFM shares to work properly the SYSTEM user must have modify access or better. The Everyone group gets special access. You can see the exact permissions assigned to EVERYONE by clicking the advanced button. They should be Read Attributes & Read Permissions. This is normal. I followed instructions from Microsoft on forcing a complete rebuild of the Mac index but that didn't work.

Here's how I was able to resolve the problem.

I noticed that when I created a new share, permissions would behave differently each time. I created shares and deleted them until I had one that worked the way it was supposed to. Then I copied (the Move command didn't work as it seemed to retain the permissions problem) data from the share with permissions inheritance problems into the working share. Since I don't have as much free space as I do data I had to do this a few directories at a time deleting the originals once they were copied. Once all data was copied over I stopped sharing both shares, deleted the original share, changed the name of the new working directory to match the name of the old directory and shared it back out again.

Three of six directories on the server were affected by this problem. The unaffected directories had the same Folder Name on the NTFS volume as the Mac Share name as the SMB Share name. The problem directories had dashes in the NTFS name and SMB share name and spaces in the Mac Share name. So in creating the new shares I have made sure all the 3 names match exactly. I don't know if this had anything to do with the original problem but it looks suspicious. I have had the name differences cause problems in the past other cross-plat applications that work with the server shares.

To illustrate the naming on the affected directories, here's how the problem folders looked:

On the server a folder was created as 'PUBLIC_FILES.' This Folder was shared to Windows clients as 'PUBLIC-FILES' and shared to Mac clients as 'PUBLIC FILES'.

June 4, 2003
Dan Tesch

I have had this problem on and off for several years now and I have always been extremely anal about naming things EXACTLY the same and I still experience the issue - with native SFM -AND- ExtremeZ-IP.

June 4, 2003
Greg LaViolette

I've seen this as well, but only when OS X users create items in a folder that doesn't have the "Everyone" group. The OS X client creates the everyone group (Others) and gives them read only access and then adds themselves as having full access. For the time being I have put the Everyone group back.

June 11, 2003
Stephen Chiang

Adding the everyone group was what I ended up doing as well.

If you've seen this problem, please let us know.

Another Permissions problem

September 24, 2003
Jay Christianson

In building some student storage space at our university we found an interesting little problem between the Macs and their Windows storage servers. The students mount a master share on the server, and then traverse to their personal folder. Within that personal folder are two more folders: one for their web site, one for storing private, non-web materials.

These two folders' permissions are set so that the folder, subfolders, and files give the student modify permissions so they can read and write at will in the folders. The folders are also marked at the "this folder only" level, to deny delete, write attributes, write extended attributes, take ownership and change permissions. This is to prevent them from removing the actual root folders from the server.

So, from PC's connecting to the servers, everything works like a charm, students can read, write, delete, or whatever within the root levels of their web and private folders. Macs, on the other hand, see the folders as read only.

In playing with the deny settings at the "this folder only" level, we found that denying any of these three items - write attribute, write extended attribute, or delete, will cause this problem for the Macs. (We've done tests and know that this affects at least Win2K and Win 2003 servers).

If a student logs into a PC, creates a subfolder within the web or private folder, they can then read, write, delete etc. within that subfolder from a Mac.

So, we're trying to figure out why the Macs (both 9 and X) can not understand the folder vs inside-the-folder permissions while the PC's can.

Macs disconnecting from Win 2K Server

This is a known problem that can be solved with a Registry edit (see below). Several readers also have workarounds.

Description of problem and workarounds:

July 17, 2003 -- Lorenz Schwarz has a problem with Mac OS X clients disconnecting from a Windows 2000 Server. He also has a workaround:

We recently bought a new Mac with OS X installed. The integration of an OS X client with a Windows 2000 Server has a problem that we don't see with our Mac OS 9.x Macs. Every 20 minutes or so the OS X Mac is disconnected with a notice that its session-time was over. Entering longer values via the default-session-time command in Windows 2000 didn't make any change.

The workaround I'm using for now: I put an older NT4 Server up again, gave it his own domain and made this domain trusting and a trusted one to the Win 2Kdomain. Then I deleted the OS X user on the Win 2K and reopened it on the NT4. The User gets no session-timeouts anymore and can connect directly to the Win 2K Domain and its Volumes.

July 22, 2003
Adam Camilleri

We have also experienced the same problem; but only when we connect via AFP. If you connect via SMB there are no disconnection problems. Copying the files to the desktop has the same effect.

We have been doing some trials with Windows 2003 Server; and there are no signs of this disconnection problem when connecting via AFP.

July 22, 2003
Pat Leary

I read your work around on this subject but I have been having this problem with almost all of my Macs OS 9 and OS X. I'm in a Win NT domain and I am not running Active directory anywhere.

July 24, 2003
Sonja Shuffler

The way I worked around this problem, was to take the Mac OS X users out of the DHCP range of IP Numbers and gave them Static IP's none of the users have dropped off since.

An explanation

July 22, 2003
Todd Miller

With Windows 2000 server, network connections time out after a specified period of time. This is why on Windows clients, mapped drives will have little red Xs on them. With a Windows client, when you try to connect again, you invisibly re-log in to the server and the drive reattaches automatically. All this happens because on an Windows machine you log into a domain and your credentials are cached. This minimizes the number of open connections on a server. Mac clients don't have this ability or feature and so when the Win 2000 server disconnects after a period of several minutes, they are kind of stuck. Don't hold me to this, but I could have sworn there was a way to disable this disconnection "feature" on Windows 2000 servers. Like there is a registry key or something. Another point I'm not positive about is that I think that Win 9x machines where you are not logged into a domain also can have this problem. Also, again off the top of my head, I don't think you are affected if you connect via AFP rather than SMB.

DAVE allows you log into the domain and so doesn't have this problem.

Solution:

July 29, 2003
James Burrows

Reading your site and saw the above problem, which I have seen before.

The solution is a Registry change of the following key :- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\autodisconnect

Set this to ffffffff and the server will never disconnect clients.

See Knowledge Base article 297684 for more info.

Norton Corporate Edition 9 on Win 2K Server breaks AFP

The first few reader reports incorrectly assumed the incompatibility was with AppleTalk, when the problem is with the Apple Filing Protocol (AFP), over AppleTalk or TCP/IP. The solution is below, reported by three different readers.

June 28, 2004
Géry Houiller reports this problem:

I've discovered a big problem about Norton Corporate Edition and Windows Server 2000.

We have installed the new NCE 9.0 on 5 PC Dell Server with Windows Server 2000 SP4 French version. Two days after, we have problem about access with Macintosh on AppleTalk channel. When we delete the installation of NCE 9 on the server, everything goes right.

August 3, 2004
Karen Bowerman

We also had the issue with Norton Antivirus CE version 9 breaking AFP over TCP/IP connections. We actually had to completely uninstall NAV 9 off the server and reboot the server to resolve the issue. Server is Windows 2000 SP4 with the latest updates and running Services for Macintosh. Both OS 9 and OS X users could no longer connect using AFP. SMB of course still worked for OS X users.

August 9, 2004
Christopher Culligan

We also have had NAV CE 9 break our AFP over TCP/IP. Intermittent connections every once in awhile can be made, but for the most part, nada.

However, on the Symantec AV server (v9.0), also running Active Directory, we don`t see the problem, so we assume its the client software only.

Also, one reader mentioned trying to use the UAM module instead of AFP standard login -- we tried that and it didn`t seem to work.

Solution

July 14, 2004
Joseph Swenson

One of our server people just spoke to Symantec's tech support and have a solution for the AppleTalk issue with NCE 9. Apparently the POP3SMTP scanner conflicts with certain items such as AppleTalk. Once you remove that component things should run OK.

August 13, 2004
Gareth Hone of London:

We had this problem in our company several months ago. I took a few weeks battling to realize the problem -- not much help from Symantec either. But we found this solution:

1) Uninstall Symantec from the file server.

2) Reinstall the AV software on the file server (on the console - NOT using the AV rollout tool)

3) When given the options on what components to install, remove the Email (POP3) scanner.

This solves the problem, but unlucky if you need to use Outlook/POP3 on your file server.

August 13, 2004
Curtis Wilcox

We encountered this problem on our Win 2000 SP4 server. There's a possible solution I found in Symantec's technical support forum. The link to the message thread is here [see the message from Franck Florentin].

Apparently the solution is to install SAV 9 without the Internet mail plugin. I consider this an acceptable solution as people should not be checking their mail from a file server anyway. I haven't tested this solution yet because our File Server for Macintosh service has crashed and we'll have to reboot in off hours to bring it back.

CrossOver 9 runs Windows apps on a Mac--without Windows Improved Outlook support, Quicken 2009, more Windows apps. Give your Mac ActiveX in Internet Explorer, launched directly from the Finder. CrossOver Games runs Left4Dead, Warcraft, Steam, Spore, and others on your Mac. Starts at only $40 (and no need to buy Windows!) Free trial from CodeWeavers. Click here for more.

---

| Top of this Windows 2000 Special Report Page |

Other MacWindows Departments